synapse: route an event by the role of the account it was delivered for ...

The dispatcher's choice of profile was checked against a hardcoded "user" role,
so an admin's own events could never reach the admin-only profiles their routing
instruction named. The event fell to whichever profile all() happened to yield
first — a profile without the tools the event needed — and the instruction looked
like it did not work. The role now comes from navi_users for the account the event
was delivered for (_user_role, failing closed to "user" and logging), and it is the
role the run carries as current_user_role.

Alongside, in the same path:

- the dispatcher is offered each profile as "id (name) — description", so a rule
  that names a profile in words has something to match it against;
- an unroutable event lands on a role-aware fallback (secretary for an admin,
  assistant otherwise) instead of the first of all(), and every substitution is
  logged as synapse.reaction_profile_downgraded with both ids;
- session_key is folded to one spelling — whitespace collapsed, lowercased — so a
  chat cannot fork on "TG:42" against "tg:42";
- the conversation rule is read from whichever instruction document states it,
  not from the dispatcher one alone.

A refused profile is still refused: hidden stays hidden for everyone, and an
admin-only profile stays out of reach for a regular user's event.

synapse: a reaction continues its conversation, and the request becomes a record ...

Every Synapse event used to open its own service session, so two messages of
one Telegram chat landed in two unrelated chats. The dispatcher now returns a
`session_key` — derived from the payload according to the user's routing
document — and a later event carrying the same key joins the session that
opened it, within `reaction_session_ttl_minutes` of idle time (0 restores the
old always-fresh behaviour). A session that is still running is never joined:
`create_run` overwrites `state.run`, so a second run would orphan the first
one's subscribers — a busy thread gets a fresh session instead. When the
dispatcher names a different profile for the event, the session's profile is
switched through `set_profile`, never through `save()`, which does not rewrite
`name` or `profile_id`: the thread keeps its name and its history.

What the user reads in the transcript is now only the request. The event
record is a system message (`metadata.source == "synapse_event"`) drawn by a
new SynapseEventNotice.vue in the visual language of the recall badge, and the
framing plus the JSON envelope become a hidden user turn written once, on the
first event of a thread — not on every one. The instructions from Settings
reach the model through a new `current_reaction_instructions` ContextVar and
the `[Reaction session]` block of the system prompt, so they appear in no
transcript at all. The stored system record still has to reach the model, so
ContextBuilder's allowlist becomes `_LLM_SYSTEM_SOURCES = {task_note,
synapse_event}`.

The dispatcher gets a document of its own — how to route, rather than what to
do — stored beside the reaction instructions, versioned separately, and edited
in its own field in the settings panel. `synapse_instruction_versions` gains a
`doc` discriminator, so existing rows keep `'reaction'` and their history
verbatim. The new columns are added by `_MIGRATE`, and the index over `doc`
lives there too: `_DDL` runs first, so an index over a column the migration has
not added yet kills the whole batch on an existing database — which is what
the prod database is. A guard test keeps it that way.

Tests: 1776 passed, 1 skipped (backend), 242 passed (webclient, 28 files).

profiles: restricted profiles for ordinary users, and a role gate that holds ...

`is_admin_only` was checked in one place out of nine and was not read from
config.json at all, so all seven profiles were reachable by every account with
role `user`. The flag now lives in config.json — the file is the baseline, a
`profile_overrides` row still wins on top of it — and one predicate,
`admin_only_blocked`, is the single place the rule is expressed. The nine
surfaces that list, switch to, spawn or resolve a profile all consult it:
`POST /sessions`, the WebSocket, switch_profile, list_profiles, the system
prompt's "Available profiles" block, spawn_agent and the Synapse reaction
runner. The prompt cache is now keyed by (profile, role), so a user's prompt
can never be served an admin's profile list.

The seven existing profiles (developer, discuss, dispatcher, modeler_3d,
navi_code, secretary, server_admin) are marked admin-only. Three new ones take
their place for ordinary users: assistant, designer_3d and coder. They share one
native tool set — ssh_exec, peer, reload_tools, create_mcp_server, test_mcp_tool,
image_view and gmail are withheld — and differ only in system prompt, model and
MCP groups. navi-web's raw `request` group, and the whole of gnexus-creds and
tgclient, are withheld too.

MCP per-user keys gain the missing half of the rule: a server that declares a
`user_key` slot is refused to anyone but an admin who has no personal key, and
is left out of their tool list entirely, instead of quietly falling back to the
owner's credential and appearing as a tool that cannot work. The refusal names
the server and points at Settings.

Also closes `GET /agents/prompts`, which served every profile's system prompt to
anyone, with no user dependency at all.

The accepted residual risk is written down in docs/profiles.md: the working
directory is a convention, not a sandbox.

Await the session pool in notify and three neighbours ...

PgSessionStore._get_pool() is async, and four call sites passed its coroutine
straight into a store constructor, so the first query inside died with
"'coroutine' object has no attribute 'fetchrow'": notify always failed, the
reaction runner never got past reading its settings, synapse_instructions was
unusable, and the BYOK resolver caught the AttributeError and silently fell
back to the default credential.

The tests missed it because each one mocked the store or the pool provider
away; the new ones run on a fake asyncpg pool with nothing faked below the tool.

synapse reactions W3: reaction runner, notify tool, gateway hookup ...

- navi/synapse/reactions.py: fire-and-forget reaction run — per-user
  reactions_enabled gate, one-shot dispatcher meta-pass (visible profiles
  only, hidden dispatcher, secretary fallback), special=True session
  headed by the resolved profile, headless agent run via the orchestrator
  run registry, finalise: app push per completion_notify +
  low-level reaction.finished/failed event to Synapse
- navi/synapse/outbound.py: source-side emit (syn_* key from env,
  silent when not configured)
- navi/tools/notify.py: notify tool — message + level (info/warning/
  intervention), both legs per push_target, honest delivered/skipped result
- push/service.py: notify_custom without cooldown
- gateway: verified + non-duplicate delivery schedules the reaction
- profiles: notify added to native tools (7 profiles)

synapse reactions W1: special sessions flag + per-user reaction settings and instruction history

handbook alignment: profile.updated mirror, health contract, Synapse gateway ...

Handbook gaps closed (10-platform auth/health/notifications):

- webhooks: handle user.profile_updated — mirror the gnexus-auth profile
  into navi_users (name, contact fields, avatar_url — new column, boot
  migration); role/permissions keep their dedicated events
- auth: avatar_url now flows through the login upsert and the API-token
  resolution path
- /health: status is now the aggregate of the sub-checks (degraded embed
  or hive no longer reports plain ok); embed probe cached for 10 s; body
  grew the machine-readable checks{} map, legacy embed/hive payloads kept
- Synapse: s2s delivery gateway — POST /webhooks/synapse (both spellings),
  per-user delivery secrets (synapse_targets, Fernet-encrypted, shown
  once), verification via gnexus-synapse v0.1.2 client lib, idempotent
  event ids; deliveries are verified and logged for now — navi generates
  no outbound events by decision; web-push stays as the local browser
  channel
- webclient settings: Synapse deliveries panel (add/revoke targets)