docs: address PR #694 round-25 (Claude R25 + Codex P2)

Round-25 (Claude bot R25 finished review + Codex P2):

Claude bot R25 verdict on `09c1c04e` was "design is ready
to merge as PR-A" with 4 minor stale-language items. All 4
addressed:

- §8 lens-5 Slot pre-creation count test: "(PR-C, post-
  AllLabels population)" + "PR-B counterpart (with empty
  AllLabels)" → "(PR-C+D+E, with --keyvizLabelsEnabled=
  true)" + "PR-B counterpart (with --keyvizLabelsEnabled=
  false, the default)". Added explicit note that PR-B vs
  PR-C+D+E counterparts differ on the flag, not on
  AllLabels length (the [5]Label array is populated from
  PR-B per round-23).
- §8 lens-5 RemoveRoute symmetric teardown test: same
  fix — "(PR-C)" + "(empty AllLabels)" → "(PR-C+D+E,
  flag on)" + "(with the flag off)". Counterpart
  assertion explained as "only the legacy slot was
  pre-created (flag off), so only it is retired".
- §7 PR-C+D+E opening sentence: "PR-C (adapter wiring +
  AllLabels population)" → "PR-C (adapter wiring only —
  AllLabels constants are already declared in PR-B as
  part of the [5]Label array)".

Codex P2: PR-B row's behavior-neutrality claim depends on
--keyvizLabelsEnabled being default-false, but PR-C+D+E
row said the flag is "added in PR-C+D+E". Implementer
following PR-C+D+E literally would conclude PR-B cannot
enforce its own gating. Fixed by:

- §7 PR-B row prepended: "PR-B introduces the
  --keyvizLabelsEnabled startup flag (default false) on
  the server binary, so the flag exists from PR-B
  onward and PR-B's behavior-neutrality claim does not
  depend on PR-C+D+E (Codex round-25 P2)".
- §7 PR-C+D+E rollout-gate paragraph: "PR-C+D+E adds
  --keyvizLabelsEnabled" → "--keyvizLabelsEnabled is
  introduced in PR-B... PR-C+D+E adds the coordinator
  override path". Clarifies PR-B introduces the flag
  for pre-creation gating; PR-C+D+E adds the
  coordinator-side override path on top, which only
  matters once adapters pass non-empty labels.

Author: bootjp