Description:
When the Build Failure Analyzer plugin is enabled, it automatically inserts a ScannerJobProperty into the configuration of any Jenkins job that does not already have it, as soon as a build is started. This results in an unsolicited configuration update, competing with Job DSL plugin, and can cause confusion for users and unnecessary configuration churn.

Steps to Reproduce:

1. Prepare a pristine Jenkins instance(e.g. with docker) without any plugins or jobs
2. Install JobConfigHistory plugin for aiding debugging
3. Create a new jenkins job for demonstration, a shell step with "echo hello world" is sufficient
4. Install and enable the Build Failure Analyzer plugin.
5. Start a build for your demo job
6. Observe that the plugin adds itself to the job configuration and triggers a config save.

Expected Behavior:
The plugin should not add a ScannerJobProperty to the job configuration unless the user explicitly configures it. The PluginImpl.shouldScan method already defaults to scanning (by returning true) if the property is missing, so there is no need to add the property by default.

Actual Behavior:
The plugin adds a ScannerJobProperty to the job configuration automatically, even when it is not required.

Impact:

• Unnecessary configuration changes are made and logged.
• combination with jobs configured by Job DSL leads to endless series of configuration updates
• Potential confusion for users and noise in configuration history.

Suggested Fix:
Remove the logic that adds ScannerJobProperty to jobs automatically in the BuildFailureScanner.onStarted method. Only add the property when the user explicitly configures it.

Alternate Fix: only add that property when opening the configuration page, but not from within  BuildFailureScanner.onStarted