docs(fa4): fix-round register rows AD-82/AD-83, AD-78 count correction, gate-script SF-7/MUST-FIX-1/3 corrections

Register (docs/architecture/retail-divergence-register.md):
- AD-78: the Character-tab dimmed count had drifted stale through two
  campaigns (still read "35" after FA4 shipped 31; now 34 after the fix
  round's three reversions). Addendum explains the full D6/SF-8 chain.
  Blast review's own SHOULD-FIX 1.
- AD-82 (new): the invented leader-tint/selection-tint colors, the
  name-text-only row click target, and the page-local (not generic
  UiTemplateListBox) world->panel selection sync -- MUST-FIX 4's
  disposition plus two items MUST-FIX 5 named as owed rows.
- AD-83 (new): the Recruit button's missing "target is a player" gate,
  previously an inline comment, not a register row -- MUST-FIX 5's third
  item. Section header bumped 61 -> 63 active rows.

Gate script (docs/research/2026-08-12-campaign-fa-test-script.md):
- SF-7: fixed step 3's self-contradiction ("only Quit" then "Disband and
  Open should ALSO be enabled").
- MUST-FIX 3: new reconnect step after the existing close/reopen step.
- MUST-FIX 4: new world-selection step under the recruit/dismiss/quit
  section.
- MUST-FIX 1: new HARD-check step for the 6/8-fellow 44%/34% truncation
  (distinct from the existing SOFT 9-member ACE-divergence note).
- MUST-FIX 2 correction: the old invite steps tested whether acdream's
  CLIENT gates the dialog on the option bits -- a mechanism that never
  existed in retail and no longer exists in acdream. Rewritten to test
  the corrected behavior (the dialog always shows regardless of the
  target's own checkbox state) and to explain what ACE-side filtering
  would look like if the local server implements it, so a tester doesn't
  misattribute ACE's behavior to a client bug.
- Renumbered steps 9-22 to 9-25 to fit the two new steps; updated the
  "what to report" section's step cross-references and rewrote its
  invite/dimming bullets to match the corrected mechanism.

Plan (docs/plans/2026-08-11-fellowship-allegiance-campaign.md):
- D7 addendum: SF-8's further correction (FellowshipShareLoot reverts
  too; only FellowshipShareXP survives as genuinely live).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/plans/2026-08-11-fellowship-allegiance-campaign.md

@@ -180,7 +180,20 @@ served by the single inbound wiring site.
   allegiance bits, with no client consumer. FA4's un-dim of these two
   REVERTS (dimmed count 31 → 33 of 50); only the fellowship SHARE rows the
   create flow/panel genuinely reads stay un-dimmed. AD-78's addendum names
-  the corrected set.]**
+  the corrected set.]** **[FA4 FIX-ROUND further correction, 2026-08-12
+  (mechanism review SF-8): "the fellowship SHARE rows... genuinely reads"
+  above overstated it — only `FellowshipShareXP` is actually READ back by
+  acdream (the Create-flow click sends it as the `shareXP` wire bit).
+  `FellowshipShareLoot`'s claimed consumer, "a second live checkbox
+  surface on the fellowship page," is not a consumer at all: nothing in
+  acdream ever reads the stored value back (`FormatStatsText` uses
+  `snapshot.ShareXp` only; the `0x00A2` Create builder carries `shareXP`
+  alone), and the live-DAT dump confirms its checkbox is a child of the
+  NOT-in-fellowship frame — invisible whenever you actually have a
+  fellowship to loot-share within. `FellowshipShareLoot` REVERTS to
+  dimmed too (dimmed count 33 → 34 of 50; net ONE row un-dimmed from the
+  pre-FA4 baseline of 35, not four). AD-78's addendum names this final
+  corrected set.]**
 - **D8 — bot-vs-ACE gates are first-class.** A second ACE
   account/character + a role-discriminated headless policy let one bot
   recruit/swear at another, with the decisive assertion on the RECRUITED