docs: FA6 — file #384 (allegiance swear ACE non-response) + register AD-87

docs/ISSUES.md #384 records the live-run evidence trail (six connected
runs, the 0.005 m distance diagnostic, the confirmation-arrival diagnostic
that never fires) behind AllegianceGateEnabled=false.

docs/architecture/retail-divergence-register.md AD-87 records the honest
divergence this deferral creates: the allegiance half of the FA6 bot gate
is written and wired but unverified end-to-end over the wire, unlike the
fellowship half which is proven live.

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

docs/ISSUES.md

@@ -24,6 +24,79 @@ What does NOT go here:
 - Every session: scan OPEN issues at start; promote/close anything we touched during the session before ending.
 - Promoting to a Phase: mark as `DONE (promoted to Phase X)` + commit SHA where the Phase entry landed.
 
+## #384 — FA6 allegiance-swear bot gate: ACE returns no response to 0x001D swear (no confirmation/0x0020/error)
+
+**Status:** OPEN — filed 2026-08-12 at Campaign FA slice FA6. The two-bot
+headless fellowship/allegiance connected gate
+(`src/AcDream.Headless/Policies/HeadlessBotPolicy.cs`,
+`FellowshipAllegianceLeaderBotPolicy`/`FellowshipAllegianceRecruitBotPolicy`)
+ran live against local ACE (`127.0.0.1:9000`, `testaccount`/`+Acdream` as
+Leader, `testaccount2`/`+Horan` as Recruit) six times across the session.
+
+**Fellowship half: PASSES live, three separate runs, and is the shipped
+automated gate.** The decisive cross-session assertion — the RECRUIT bot's
+own `RuntimeFellowshipState` (a separate process's canonical Runtime owner,
+not the Leader's local echo) flipping `IsInFellowship=true`,
+`MemberCount=2`, `LeaderGuid=0x5000000A` — passed identically in runs 1, 3,
+5, and 6. Proximity via retail's admin `@teleallto` plus
+`RuntimeFriendlyTargetQuery.FindPlayerByName` (added this slice) reliably
+resolves the Recruit bot's guid even with a third, unrelated character
+online on the same shared ACE dev instance (`+Je`, `0x50000001` — see the
+`FindPlayerByName` doc comment and its conformance tests for that finding).
+
+**Allegiance half: BLOCKED, disabled by default
+(`AllegianceGateEnabled = false` in both policy classes).** After the
+fellowship establishes, the Recruit bot sends `Event_SwearAllegiance`
+(`0x001D`) with the Leader's guid as `targetGuid`. Per
+`docs/research/2026-08-11-fa-allegiance-wire.md` §1.3, retail's server
+should then send the Leader (the would-be patron) a generic
+`Character.ConfirmationRequest` (`0x0274`, `ConfirmationType=1`
+`ALLEGIANCE_SWEAR_CONFIRM`), which the Leader answers with
+`Event_ConfirmationResponse` (`0x0275`) before ACE forms the allegiance and
+broadcasts `0x0020` to both. **Live evidence (run6, with a distance
+diagnostic and a confirmation-arrival diagnostic both added for this
+investigation and kept permanently in the code):**
+
+- `[fa6-diag] distance self(0x5000000B)->patron(0x5000000A) = 0.005 m` —
+  the two bots were essentially coincident at the moment of swear, ruling
+  out retail's server-side 2.0 m swear-distance gate as the cause.
+- `HeadlessSessionHost`'s `OnConfirmationRequest` (wired this slice — it
+  was `null` pre-FA6, so headless bots dropped every confirmation
+  regardless) never fires: no `[fa6-diag] OnConfirmationRequest received`
+  line ever appears after the swear is sent, in any of runs 1, 3, 4, 5, or
+  6 (run 2 targeted the wrong player entirely, see the `FindPlayerByName`
+  history above, and is not evidence either way).
+- No `[weenie-error]` line appears after the swear either (the two
+  `0x051D` lines present in every run's log are pre-existing noise already
+  noted in the OP7 gate result, unrelated and present before any FA6
+  action fires).
+
+**ACE returns absolutely nothing** — no confirmation, no tree update, no
+error — to a `0x001D` sent at 0.005 m. This is ambiguous between (a) a
+defect in acdream's own `0x001D` wire builder (`AllegianceRequests.
+BuildSwear`) that ACE silently can't parse, (b) an ACE-side rule this
+specific test pair trips that this campaign's research didn't surface
+(GM-flagged accounts, a self/rank/loyalty precondition, a `+`-prefixed
+test-character exclusion), or (c) a genuine drop somewhere in the
+session's send path. Disambiguating (a) from (b)/(c) needs visibility this
+automated harness doesn't have — either an ACE server-side console/log, or
+a WireMCP capture correlated tightly enough to confirm bytes actually left
+the process (the two capture attempts this session used the wrong
+interface/tooling and were inconclusive).
+
+**Not investigated further this session per user direction** — the
+fellowship half is the proven, shipped automated gate; the allegiance half
+is deferred to the user's own connected gate (manual swear via the
+graphical client between two characters), which will settle whether the
+symptom reproduces outside the headless harness at all.
+
+**To re-enable:** flip `AllegianceGateEnabled` to `true` in both
+`FellowshipAllegianceLeaderBotPolicy` and
+`FellowshipAllegianceRecruitBotPolicy` — every allegiance stage (Leader's
+`WaitForVassal`, Recruit's `Swear`/`WaitSwornSeed`/`Break`/
+`WaitBrokenSeed`) is still fully written and wired, just unreachable while
+the flag is off.
+
 ## #383 — Installed-DAT vs committed-fixture drift: regeneration produces large diffs in existing UI fixtures
 
 **Status:** OPEN — filed 2026-08-12 at Campaign FA slice FA3. Running the