Fix parent-child scalar configuration inheritance

[catlover-bot]

Summary

Rework parent/child configuration merging so scalar options inherit the parent value when they are omitted from a parsed child configuration.

This implements the merge policy proposed in #6240 and discussed in #5724:

A child configuration overrides a parent scalar option only when that option is explicitly present in the child configuration. If it is omitted, the parent value is preserved.

The affected options are:

• indentation
• allow_zero_lintable_files
• strict
• lenient
• baseline
• write_baseline
• check_for_updates

Explicit child values still override parent values, including explicit false values.

Existing specialized behavior remains unchanged for:

• included / excluded
• warning_threshold
• rule configuration and enable/disable merging
• reporter
• cache_path

reporter and cache_path are intentionally left unchanged pending confirmation of the intended scope in #6240.

Implementation

Parsed configurations track which inheritable scalar keys were explicitly specified.

During merged(withChild:):

• explicitly configured child value → child wins
• omitted parsed child value → parent is preserved
• configurations without explicit-key provenance retain the historical child-precedence behavior

The provenance metadata is not part of Configuration equality or hashing because it is merge metadata rather than effective configuration state.

Testing

• Added tests for parent inheritance across all affected scalar options
• Added tests for explicit child overrides
• Added parent_config and child_config file-level regression tests
• Added nested .swiftlint.yml regression coverage
• Preserved programmatic Configuration merge behavior
• swift test: 1093 tests in 374 suites passed
• swift build --product swiftlint: passed
• make: passed
• git diff --check: passed
• Reproduced allow_zero_lintable_files: true doesn't work when added to a parent config that's loaded by a child config #6240 with a parent setting allow_zero_lintable_files: true; lint now exits successfully with zero lintable files

This PR remains a draft while confirming the final scope of the breaking configuration change.

Closes #6240
Related: #5724

[SwiftLintBot]

	20 Messages
📖	Building this branch resulted in a binary size of 28466.54 KiB vs 28460.51 KiB when built on main (0% larger).
📖	Linting Aerial with this PR took 0.61 s vs 0.65 s on main (6% faster).
📖	Linting Alamofire with this PR took 0.93 s vs 0.92 s on main (1% slower).
📖	Linting Brave with this PR took 5.93 s vs 5.85 s on main (1% slower).
📖	Linting Brigade with this PR took 15.86 s vs 15.85 s on main (0% slower).
📖	Linting DuckDuckGo with this PR took 27.86 s vs 27.52 s on main (1% slower).
📖	Linting Firefox with this PR took 10.41 s vs 10.43 s on main (0% faster).
📖	Linting Kickstarter with this PR took 6.77 s vs 6.79 s on main (0% faster).
📖	Linting Moya with this PR took 0.36 s vs 0.38 s on main (5% faster).
📖	Linting NetNewsWire with this PR took 2.32 s vs 2.32 s on main (0% slower).
📖	Linting Nimble with this PR took 0.56 s vs 0.55 s on main (1% slower).
📖	Linting PocketCasts with this PR took 6.83 s vs 6.88 s on main (0% faster).
📖	Linting Quick with this PR took 0.36 s vs 0.34 s on main (5% slower).
📖	Linting Realm with this PR took 2.88 s vs 2.81 s on main (2% slower).
📖	Linting Sourcery with this PR took 1.61 s vs 1.57 s on main (2% slower).
📖	Linting Swift with this PR took 4.18 s vs 4.21 s on main (0% faster).
📖	Linting SwiftLintPerformanceTests with this PR took 0.16 s vs 0.16 s on main (0% slower).
📖	Linting VLC with this PR took 1.22 s vs 1.25 s on main (2% faster).
📖	Linting Wire with this PR took 15.27 s vs 15.29 s on main (0% faster).
📖	Linting WordPress with this PR took 9.51 s vs 9.54 s on main (0% faster).

Generated by 🚫 Danger

[SimplyDanny]

This is not sufficient and leads to inconsistencies. Please check my last comment in #6240.

[catlover-bot]

Thanks for pointing this out. I agree that handling only allow_zero_lintable_files would make the configuration semantics inconsistent.

I am moving this PR back to draft while reworking the change around a consistent parent/child merge policy. I have posted the proposed concept on #6240 before making the broader breaking change.