Rewrite the repo-state section: this is a fork, and master is current

[SwatX18]

§2.3 was titled "Repo-state warning: the released v2.5.0 is not on master" and opened with "Read this before basing work on master". Every figure in it was wrong, and the central claim was inverted.

§2.3 claimed	Ground truth
only tag is v2.5.0	v2.5.0 and v2.6.0
"not an ancestor of master"	is an ancestor
master at 919a9f2, version 2.3.1.1	79a5cbd, version 2.6.0
v2.5.0 7 ahead, master 2 ahead	v2.5.0 0 ahead, master 56 ahead
seven commits "absent from master"	all seven in master
"building master gives 2.3.1.1 behaviour"	master builds 2.6.0

The section was never invented

Every one of those numbers is still true of upstream/master, which sits at 919a9f2 with AssemblyVersion 2.3.1.1 and v2.5.0 genuinely unmerged. It was accurate about a different repository, and it froze there while this fork moved 61 commits out from under it.

That is now said in the text, because a reader who reconstructs it from the git history has already been misled once.

So the warning changed shape rather than disappearing

The faithful two-sentence version — "two tags, both ancestors, master is current" — would discard the fact that replaced the old warning. What a contributor now gets wrong before they can notice is that this is a fork whose master has diverged from upstream's.

The rewritten section states a convention the guide never had:

Upstream is a different repository, and a bare master here never means it. Throughout this guide master is this fork's; upstream's is written upstream/master […] Unless a number is explicitly called this fork's, every #NNN below is an upstream issue or PR that git log here will never show landing.

Checked, not asserted: 25 upstream numbers cited against exactly 2 fork ones, both already named as such — hence "unless explicitly called this fork's" rather than a false absolute that would itself have gone stale.

Provenance, stated precisely

The colour-settings work was written upstream on feature/add-color-settings, which v2.5.0 tags mid-branch. master took that branch's head (18e54cd, three commits past the tag) through the merge 4fb598c, which reached master in this fork's PR #2 alongside fixes for six blocking defects it carried.

Upstream PR juv#140 is still open — the code is here because the branch was merged, not because that PR landed.

Dead branches keep their names, lose their counts

Refactoring_to_WPF, Dynamic_VibranceGUI and temp are described as abandoned 2014–2016 and more than a hundred commits behind. The old 3 ahead / 171 behind decays on every merge, and a stale count is what put this section here.

Where 2.3.1.1 had propagated

Also corrected: the guide's own provenance note, the §4 repo map, and the window title in two sequence diagrams (§6.1, §10.1). buildFormTitleText (Program.cs:395) reads Application.ProductVersion, which with no AssemblyInformationalVersion present resolves to AssemblyFileVersion — 2.6.0. Plus three places describing feature/add-color-settings as unmerged.

Verification

40 insertions / 30 deletions, docs/CODEBASE_GUIDE.md only. CR 2571 == LF 2571, no BOM, trailing CRLF. Every figure re-derived with git merge-base --is-ancestor, git rev-list --left-right --count, git tag and AssemblyInfo.cs rather than taken from the brief.

Listed, not fixed

§9.1's INI table carries 13 stale items — including affectPrimaryMonitorOnly and neverSwitchResolution documented as defaulting to "false" when SettingsController.cs:291,299 passes "true", and four keys missing entirely. Separate concern, separate change.