chore(analyzers)!: adopt the 3.43.2 analyzer baseline

[glennawatson]

What kind of change does this PR introduce?

Build and maintenance, with one breaking change to the public surface.

What is the new behavior?

The repo builds against the 3.43.2 analyzer baseline and the shared .editorconfig, and public tuple element names are PascalCase.

• Tuple element names on the public surface are PascalCase. WhenAnyValue, WhenChanged and WhenChanging return (T1 Property1, T2 Property2, ...) for arities 2 through 16, and Bind returns IReactiveBinding<TView, (object? View, bool IsViewModel)>.
  • The generator emits the same casing, so the generated fast path and RuntimeObservationFallback no longer disagree about what an element is called.
• StyleSharp, PerformanceSharp and SecuritySharp move to 3.43.2, and the code conforms to the rules that brings with it.
• Microsoft.Maui.Controls on net11 moves to 11.0.0-preview.7.26406.9, which is the version the MAUI workload that builds that leg expects. Roslyn stays pinned at the 4.8.0 shipping floor, so the minimum consumer SDK is unchanged.
• Two rules are scoped rather than satisfied.
  • SST2334 is off for tests and benchmarks: a fixture or a harness is read through assertions, not a debugger summary. Product code still enforces it.
  • SST2461 is suppressed on the DynamicallyAccessedMemberTypes polyfill, whose values must stay numerically identical to the BCL enum the newer targets type-forward to.

What is the current behavior?

• Analyzers sit at 3.39.2 and the repo predates the shared .editorconfig.
• Public tuple elements are camelCase (x.property1, x.view), and disagree with RuntimeObservationFallback, which already returned PascalCase elements.
• Microsoft.Maui.Controls on net11 is pinned to preview.6.
• InitialEmitCompetitor in the initial-emit serialization test claims its turn with a plain bool check-then-set. Two threads can pass it, which throws out of the source's event handler or stalls instead of reporting the emission sequence - in the test that exists to catch exactly that class of race.

What might this PR break?

• Renaming public tuple elements is a source break for consumers. A caller reading x.property1 or x.view must read x.Property1 or x.View. Element names are metadata only, so existing binaries keep working and only recompilation is affected.
• Generated output changes. Consumers who assert on generated text will see the new element casing, and the dispatch line numbers move for any fixture whose call site shifted.
• Nothing else changes at runtime. The scheduler seam, the dispatch mechanism and the lean / .Reactive split are untouched.

Checklist

• I have read the Contribute guide
• Tests have been added or updated (for bug fixes / features)
• Docs have been added or updated (for bug fixes / features)
• Changes target the main branch
• PR title follows Conventional Commits

Additional information

Most of the diff is mechanical; the hand-written parts are a short list.

Mechanical, and safe to skim:

• Regenerated *.g.verified.cs snapshots - element casing, plus dispatch line numbers and their derived method-name hashes.
• [MethodImpl(MethodImplOptions.AggressiveInlining)] attributes and their imports, applied where the analyzer reported them.
• The tuple element renames themselves, across the wide-arity and selector files.

Worth actual review:

• src/Directory.Packages.props, src/tests/.editorconfig, src/benchmarks/.editorconfig
• CodeGeneration/BindCodeGenerator.cs and CodeGeneration/ObservationCodeGenerator.cs - the two places the generator emitted tuple element names as literals
• Polyfills/DynamicallyAccessedMemberTypes.cs - the suppression and its justification
• Observables/PropertyChangingObservableInitialEmitSerializationTests.cs - the latch now uses Interlocked.Exchange
• Wpf.Shared/BooleanToVisibilityTypeConverter.cs - restructured into an early-exit guard; both original branch expressions are preserved verbatim
• The <exception> documentation added across the binding mixins, and the DebuggerDisplay strings on the runtime types

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
94.8% Coverage on New Code
2.2% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

❌ Patch coverage is 97.41379% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.55%. Comparing base (92f770d) to head (98ae845).

Files with missing lines	Patch %	Lines
...pf.Shared/DependencyObjectObservableForProperty.cs	0.00%	2 Missing ⚠️
...nding.SourceGenerators/Helpers/CommandExtractor.cs	80.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #68      +/-   ##
==========================================
- Coverage   97.56%   97.55%   -0.01%     
==========================================
  Files         228      228              
  Lines        7840     7826      -14     
  Branches     1077     1071       -6     
==========================================
- Hits         7649     7635      -14     
  Misses        143      143              
  Partials       48       48              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.