docs: FA4 review — correct D6/D7 (server-side invite filter) + record D8 account/proximity

D6 asserted the client consumes IgnoreFellowshipRequests/
FellowshipAutoAcceptRequests on the invite path; the FA4 mechanism review
(913e35cd MUST-FIX 2) byte-verified retail reads NEITHER bit client-side
(Handle_Character__ConfirmationRequest @0x005640A0, RecvNotice_
FellowshipRequest @0x00490880, MakeFellowRequestDialog @0x00490620) — ACE
filters both server-side. Same class as the D2 reset-lifetime correction.
D6/D7 corrected in-place with dated addenda: the client-side intercept is
removed, the invite dialog always shows, and the two un-dims revert
(dimmed 31->33). D8 records the user-provided second account
(testaccount2/testpassword2) and the recruit-proximity requirement.

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

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

@@ -150,22 +150,48 @@ served by the single inbound wiring site.
   acdream's `RetailDialogFactory`/`GameplayConfirmationController`
   already match the constants and its own comment names these types as
   awaiting FA. The missing third message of the triple is completed in
-  FA1. The invite-receive path consumes `IgnoreFellowshipRequests` /
+  FA1. ~~The invite-receive path consumes `IgnoreFellowshipRequests` /
   `FellowshipAutoAcceptRequests` (auto-decline / auto-accept before the
-  dialog), giving those two dimmed rows their real consumers.
+  dialog), giving those two dimmed rows their real consumers.~~ **[FA4
+  mechanism-review correction, 2026-08-12 (`913e35cd` MUST-FIX 2): retail's
+  client does NOT read either option bit on the invite/confirmation path —
+  byte-verified across `Handle_Character__ConfirmationRequest @0x005640A0`,
+  `RecvNotice_FellowshipRequest @0x00490880`, and `MakeFellowRequestDialog
+  @0x00490620` (whose ONLY guard is `m_fellowRequestContext`), plus a
+  whole-file sweep of both accessors: zero option reads anywhere on the
+  path. ACE filters both bits SERVER-SIDE. So there is NO client-side
+  auto-response: the fellow-invite dialog (type 4) always shows through the
+  generic `GameplayConfirmationController`, exactly as retail does. The
+  client-side intercept FA4 shipped is removed. `IgnoreFellowshipRequests`
+  defaults TRUE, so a client-side intercept would additionally have
+  silently swallowed real invites against any server that didn't filter —
+  a real hazard, not just a fidelity nit.]**
 - **D7 — dimming resolves per lane-C/D verdicts.** Un-dim (with the AD-78
   conformance-test flow) exactly the rows that gain consumers:
-  `IgnoreFellowshipRequests`, `FellowshipAutoAcceptRequests` (D6), and
+  ~~`IgnoreFellowshipRequests`, `FellowshipAutoAcceptRequests` (D6), and~~
   the fellowship share rows consumed by the create flow/panel display.
   `IgnoreAllegianceRequests` and `DisplayAllegianceLogonNotifications`
   stay dimmed PERMANENTLY and faithfully — retail's own client has no
   consumer for either (pure server-side filters); AD-78's register row
-  gains an addendum saying so.
+  gains an addendum saying so. **[FA4 mechanism-review correction,
+  2026-08-12: following D6's correction, `IgnoreFellowshipRequests` and
+  `FellowshipAutoAcceptRequests` ALSO stay dimmed PERMANENTLY and
+  faithfully — they are pure server-side filters exactly like the two
+  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.]**
 - **D8 — bot-vs-ACE gates are first-class.** A second ACE
-  account/character (user-provided when FA6 arrives) + a
-  role-discriminated headless policy let one bot recruit/swear at
-  another, with the decisive assertion on the RECRUITED bot's own
-  snapshot. All six FA option names are already tier-1 allow-listed.
+  account/character + a role-discriminated headless policy let one bot
+  recruit/swear at another, with the decisive assertion on the RECRUITED
+  bot's own snapshot. All six FA option names are already tier-1
+  allow-listed. **[User-provided 2026-08-12: the second account is
+  `testaccount2` / `testpassword2` on the same local ACE. RECRUIT REQUIRES
+  PROXIMITY — the recruiting character must be quite close to the recruit
+  target, so the FA6 bot gate must position the two bot characters near
+  each other (same landblock/adjacent) BEFORE the recruit command, or the
+  recruit fails; the FA4 §FA4 [TWO-CLIENT] recruit step notes the same for
+  the manual path.]**
 - **D9 —** ~~the 8 missing fellowship WeenieError strings are added in FA1
   (two are on ACE's live send paths today; all resolve from the DAT
   string tables, never invented).~~ **[FA1 fix-round addendum, 2026-08-12: