fix(ui): FA4 re-review REOPEN — re-declare 0x00A6 from the post-world seam, not the pre-world reset

The FA4 fix round's MUST-FIX 3 placed the 0x00A6 reconnect re-arm at the
wrong lifecycle point (re-review 8bbceff5): ResetSessionTransientUi runs
via the SessionDialogs reset stage BEFORE _inWorld=true, so SetPanelOpen
(world-gated, Validate requireWorld:true) returned Inactive and published
nothing — yet _pageVisible was latched true anyway, so no later hook
re-declared and fellow vitals stayed frozen for the whole new session.
The unit test passed only because the fake recorded unconditionally.

Two-part fix, both retail-faithful mechanisms not suppressions:
- SocialFellowshipPageController.SetPageVisible advances the edge-trigger
  latch ONLY when the declaration is Accepted (published), so a dropped
  pre-world send leaves the latch clear and a later attempt retries.
- ResetSessionDeclaration (pre-world) now ONLY clears the latch; the new
  RedeclareAfterWorldEntry fires from the LiveSession EnteredWorld seam
  (wired via RestoreLayout, idempotent if a persisted layout already
  re-showed the page) so a still-open Fellowship page re-declares 0x00A6
  in world and vitals resume.

Regression pins that actually catch it (the prior test could not):
- SetPageVisible_DoesNotLatch_WhenDeclarationDropped_SoItRetriesInWorld
  (widget-level root, world-gated fake);
- Reconnect_ReDeclares0x00A6_AfterWorldEntry_NotDuringPreWorldReset +
  Reconnect_StaysSilent_WhenFellowshipPageIsNotActuallyOpen (panel-level,
  world-gated). RED-verified: reintroducing the pre-world declaration
  fails the reconnect test.

Full Release suite: 13,286 passed / 4 skipped / 0 failed.

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

docs/research/2026-08-12-campaign-fa-test-script.md

@@ -328,8 +328,12 @@ behavior when closed — [TWO-CLIENT], the `0x00A6` gate made observable
    step 7's damage-and-watch check). EXPECTED: vitals update normally on
    the new session, exactly as before the reconnect. BUG if vitals stay
    frozen for the rest of the new session — that means `0x00A6` was
-   never re-declared after the generation reset
-   (`SocialPanelController.ResetSessionDeclaration`).
+   never re-declared after the generation reset. (Re-review re-fix
+   2026-08-12: the re-declaration fires from the post-world
+   `EnteredWorld` seam via `SocialPanelController.RedeclareAfterWorldEntry`,
+   NOT the pre-world `ResetSessionDeclaration`, which only clears the
+   latch — declaring before world entry was silently dropped by the
+   world-gated command, the original defect.)
 10. **Your OWN row's vitals should always update** (your own vitals are
     driven by the existing player-vitals pipeline, not the fellowship
     `0x02C0` stream) — this is expected and not a sign that `0x00A6` is