fix(chat): CH4 re-review fixes — dialog-queue reentrancy, settings option-bit chokepoint

Should-fix 1: RetailDialogFactory.CloseDialog's queued branch removed the
active DialogInfo, ran DialogDone (whose callback can synchronously open a
new dialog under the SAME queue key — the two-stage house-abandon
confirmation does exactly this), then called OpenNextDialog, which did an
unconditional Dictionary.Add on a key the reentrant dialog had already
re-occupied. Retail's HashTable::add tolerates the duplicate; Dictionary
throws. OpenNextDialog now returns early when the queue key is already
active — the reentrant dialog's own eventual close drains the queue.

Should-fix 2: @join/@leave wrote the local RuntimeCharacterOptionsState bit
before sending, but the Settings Chat toggles reached a second binding
(SendSingleCharacterOption) that only sent the wire message, leaving the
Turbine membership gate stale until the next PlayerDescription.
LiveSessionRuntimeFactory.CreateCommandBindings now has one shared local
function for both entrances.

Should-fix 3: corrected TS-68/#360 wording again — retail's DoAllegiance
dispatcher table EXECUTES boot/ban/officer/title/motd/name/lock/house/
chat/broadcast locally through their own handlers; acdream shows the
unrecognized-subcommand refusal for all nine pending the #360 port. What
matches retail is the ownership rule (the verb never reaches
DoChannelCommand/the server), not the subcommand behavior itself. Removed
the inaccurate "matching retail, not merely harmless" / "now matches
this" claims from both the register row and the issue.

Nits: corrected the HouseAbandonDialogCallback_First citation (0x00580E1A
is DoHouse's load site for the callback pointer, not the function entry —
the entry is 0x00580240, with the stage-2 confirmation string built at
0x005802D8) in both ClientCommandController.cs and the mirrored test
comment; added an InlineData case pinning "@clist allegiance" to
RequestChannelList(0x02000000); converted RetailClientCommandCatalog.
KnownVerbs from a plain array to a FrozenSet<string> with
StringComparer.OrdinalIgnoreCase, matching the file's other lookup tables.

Suite: 12,221 passed / 4 skipped / 0 failed (Release), up from CH4's
12,216/4/0 — net +5 tests, no removals.

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

docs/ISSUES.md

@@ -54,9 +54,25 @@ this command." locally and stays entirely client-side
 CH4 REJECT-review found acdream had instead been broadcasting the
 unmatched subcommand text to the Allegiance chat channel — a real
 chat-visible bug, now fixed (`TryMatchAllegiance` claims ownership
-unconditionally and shows retail's own refusal text). The 22 subcommands
-themselves still don't execute; only the fallback behavior changed.
-Register row: TS-68. Registry doc:
+unconditionally and shows retail's own refusal text).
+
+**Corrected again 2026-08-09 at the CH4 re-review (SHOULD-FIX 3), for
+precision:** the nine allegiance subcommands (boot, ban, officer, title,
+motd, name, lock, house, chat, broadcast) are NOT refused by retail —
+`DoAllegiance`'s dispatcher table EXECUTES each one locally through its
+own handler (e.g. `DoAllegianceBoot @ 0x0057D646` is the dispatcher's
+call site into `ClientCommunicationSystem::DoAllegianceBoot`, with
+`DoAllegianceBan`/`DoAllegianceOfficer`/`DoAllegianceOfficerTitle`/
+`DoMotd`/`DoAllegianceName`/`DoAllegianceLock`/`DoAllegianceHouse` its
+siblings in the same table). acdream shows the same unrecognized-
+subcommand refusal for all nine because none of those handlers is
+ported yet, pending this issue. What matches retail is the OWNERSHIP
+RULE — the verb never reaches `DoChannelCommand`/the server regardless
+of subcommand — NOT the subcommand's actual behavior, which retail
+executes and acdream does not.
+
+The 22 subcommands themselves still don't execute; only the fallback
+behavior changed. Register row: TS-68. Registry doc:
 `docs/research/2026-08-09-chat-retail-command-registry.md` §2.5/§2.5b.
 
 ## #361 — @day / @log / @render pure-local commands recognized in help only, not executed