[Docs]: Ten statements in ARCHITECTURE, README, CONTRIBUTING and TESTING describe code that has changed

[laurentiu021]

Problem

Ten statements across the docs describe code that has since changed. Each was re-derived from current source, and the two that turned out to be false alarms are listed at the bottom so nobody re-raises them.

ARCHITECTURE.md

Claim	Reality
"The four Network tabs also stay eager because they share one NetworkSharedState and their constructors do no work"	They are lazy. ArchitectureTests.OnlyTheJustifiedTabs_AreBuiltAtStartup allows exactly three: Dashboard, Dark Mode Scheduler, About — anything else eager fails the build
the in-app Console is "used by Cleanup, Windows Update, System Health, App Updates, and Uninstaller"	UninstallerView.xaml binds no console at all — zero occurrences
"Thirteen are registered against their implementation in ServiceRegistration.cs"	Fourteen, counting both AddTransient<I…,…> and the two factory registrations (ISessionRestorePoint, IGamingProfileService). The enumeration also omits ICleanupPreScanService
TracerouteService probes are built on "System.Net.NetworkInformation.Ping and tracert"	tracert has never existed in this codebase — zero occurrences in any .cs

README.md

Claim	Reality
collapsed groups show "a subtitle with abbreviated child labels"	Subtitles are written per-group copy since #1518, and EverySidebarGroupSubtitle_IsWrittenCopyThatFitsTwoLines now fails the abbreviated shape
"Each tab shows a slim progress bar under its name when performing a long-running operation"	11 of the 55 tab view-models never assign IsBusy, so their tabs never show the bar. The slowest tabs in the app are among them: Speed Test, Traceroute, Ping, Network Repair
tray "Context menu: Show / Exit"	Three items, and the first is not called Show: Show SysManager, Volume mixer, Exit. The README's own Volume Control section describes the Volume mixer shortcut, so the page contradicts itself

CONTRIBUTING.md / TESTING.md

Claim	Reality
"All 688 of them carry it" (author headers)	704 .cs/.xaml files carry the header — 16 stale
"CI runs this on all four projects", followed by a one-project command	ci.yml does loop over all four; the copyable command checks only SysManager.csproj, so following the doc misses three
framework table pins "NSubstitute 6.1"	Directory.Packages.props pins 6.2.0

Source XML docs

• NavGroup.Subtitle — "Abbreviated child labels joined with ·". It is written copy now; the mechanism the sentence describes is gone.

Expected behavior

One docs pass fixes all of these. Two deserve more than a wording change:

• The progress-bar claim is a behaviour gap, not a wording problem. Speed Test, Traceroute, Ping and Network Repair are exactly the tabs a user waits on. The right fix is to have them set IsBusy like the other 44 view-models, which keeps the README true and closes a real UX hole. Filed as its own item if that is preferred over weakening the sentence.
• The eager-tabs paragraph contradicts an enforced guard. Worth writing so it cannot drift again: name the three justified tabs and point at the test, rather than restating a list that has to be maintained by hand.

Refuted — do not re-raise

• Dashboard is not missing the progress bar. It assigns IsBusy in two places. Only the 11 listed view-models never do.
• WindowsUpdateView's columns are not editable despite 10 of 11 lacking a per-column IsReadOnly, and neither are 19 other views' — they set IsReadOnly on the DataGrid element, which covers every column. The genuinely editable grids are tracked separately in [Bug]: Seven report grids let the user type into cells that discard the edit #2105.

Affected area

Documentation (ARCHITECTURE.md, README.md, CONTRIBUTING.md, TESTING.md) and one source XML doc

[laurentiu021]

The behaviour half shipped in v1.76.13 via #2114, so the README's progress-bar sentence is now true rather than reworded.

Five view-models were keeping a running flag and never assigning IsBusy: Speed Test, Traceroute, Network Repair, About and DNS & Hosts — the slowest screens in the app. Each now forwards it through a generated On…Changed hook, and EveryViewModelThatTracksRunningState_ForwardsItToIsBusy fails the build if a new one does not.

Worth recording because it corrected my own first measurement: looking for On…Changed hooks reported 16 unforwarded flags. That was wrong — several tabs assign IsBusy inline in the command body, which is equally correct. Asking "does this view-model assign IsBusy anywhere at all" gave the real answer of five.