fix(brain): llm-wiki papercuts — duplicate member 400, account-email resolution, supervise ticks

[futurepaul]

Fast follow to the 2026-08-18 brain release, fixing the brain-related papercuts filed in the finite-mono-llm-wiki workaround reports (workarounds-log/reports/, 2026-08-18/19). Four of the five reports are addressed; the fifth (vision_analyze Spark 502, 2026-08-17) is a provider-side vision failure with no brain-side fix and is not addressed here.

Fixes

admin member add 500 on already-member targets (2026-08-19-fbrain-admin-member-add-500.md)
add_member_with_control_records inserted into brain_members without a duplicate check, so an already-member target hit the primary key and surfaced as a bare 500 internal server error. The store now returns the same broken invariant: target is already a brain member 400 the invitation path returns. ensure-access is unaffected (it short-circuits on its own membership check before calling the store; under a concurrent race it now also gets the clean 400 instead of a 500).

admin ensure-access --target <email> → NIP-05 502 (2026-08-19-fbrain-ensure-access-email-502.md)
Non-finite.vip email targets were resolved only through public NIP-05 (https://gmail.com/.well-known/nostr.json → 502 transport), while invite brain create resolves the same email through the Finite Core account-agent roster. resolve_identity_input now resolves account emails through the same roster + identity user-resolution authorities first, falling back to NIP-05 when the email binds to no Finite account. This unifies email resolution across admin member add/remove, admin role grant/revoke, admin folder-access grant/revoke, admin ensure-access, and collaborator ensure-admin. finite.vip identifiers deliberately stay on the NIP-05 path — it is already routed to the identity authority and answers for managed agent mailboxes (deviating here also changes the departure-fact consumer's resolution sequence).

fbrain daemon not ticking (2026-08-18-fbrain-daemon-not-ticking.md)
daemon supervise workers never wrote tickCount/lastTickAt, so even a healthy supervisor reported tickCount: 0, lastTickAt: null forever — indistinguishable from the wedged daemon the report suspected. Successful notification syncs now record a supervisor tick; failures keep incrementing failureCount and persist the reason in daemon.lastError / daemon.sync_blocked activity (visible via fbrain daemon logs). The reporter's underlying per-tick failure was environment divergence in the hosted daemon (failure string is persisted in daemon logs); the status surface no longer hides daemon health.

Stale vault-era skill surface (2026-08-18-fbrain-skill-vs-cli-mismatch.md)
The repo's SKILL.md was already hard-cut to the Brain-era surface in 7d48291 — the report hit an un-refreshed managed-skills checkout in the hosted runtime, which picks the fix up on refresh. What was still stale in-repo: fbrain-cli.md (both packaged copies) documented admin targets as npub-only. Aligned the reference and the folder-access help line with the real <email|NIP-05|npub> surface, which the email-resolution fix above now actually delivers.

Testing

• 6 new tests: duplicate member add → 400; roster-first resolution for account emails; NIP-05 fallback on unbound email and on roster mailbox mismatch; finite.vip stays off the roster path; supervisor outcome tick/failure bookkeeping.
• cargo test for finite-brain-{store,server,cli,core}: all green; cargo fmt --check and cargo clippy clean.
• End-to-end against a fresh devfinity services-only stack (probe driven by the locally built fbrain): admin member add --target devfinity@finite.computer resolves through Core+identity and adds; the duplicate add returns 400 {"error":"broken invariant: target is already a brain member"}; admin ensure-access --target devfinity@finite.computer returns membership: alreadyMember, state: complete.
• just dev smoke passes.
• just skills check passes (reference-copy sync enforced).

Notes for reviewers

• CoreAccountAgentRosterResponse/CoreRosterAgentEntry moved from routes/invitation_plans.rs to lib.rs so the shared resolution path can use them; the invitation plan flow is unchanged.
• Locally observed (also on clean origin/main, so pre-existing and out of scope here): authority_boundary_classifies_status_malformed_and_oversized_without_body_leaks intermittently classifies the fake authority's 503 as transport on darwin.