designer_3d: the sub-agent gets what the prompt promises it, and weather goes ...

The profile prompt tells a sub-agent it may use web search, page reading,
filesystem reads and image viewing, and that it must not write, publish,
share, run commands, update todos or call the modelling tools. The declared
sub-agent set said otherwise on both counts: it carried terminal, code_exec,
share_file, content_publish, todo and the whole navi-3d server, and it lacked
the image_view the prompt grants. It is now scratchpad, reflect, filesystem,
image_view, memory, list_tools, tool_manual plus navi-web (search, browse).

weather leaves designer_3d. It was declared in the profile and also merged
into every profile from tools/enabled.json, so both had to go; assistant and
secretary declare it themselves and keep it, and the admin-only profiles that
never asked for it lose it too. Since switch_profile unions the two restricted
profiles, this trims the 3D agent's schema rather than closing a door.

The agent's own set keeps terminal, code_exec, share_file and tasks — the
owner reports real use for them.

profiles: give the restricted profiles image_view ...

The 3D designer renders PNG previews with mcp__navi-3d__render_stl and then
had no way to look at them: image_view was withheld from all three
restricted profiles, and designer_3d's system prompt said so outright
("You cannot look at the render yourself"). It shipped geometry it had
never seen, with only lint/compile output behind it.

Add image_view to all three rather than to designer_3d alone. The three
sets are kept identical precisely because switch_profile lets a session
move between them, so a restricted session can reach image_view from any
of the three anyway; putting it in one profile would have made the
restriction look like a boundary it is not.

designer_3d now has to call it on every preview the renderer returned
(one angle is not enough), fix what it sees, and treat the visual check
as an addition to the mechanical ones rather than a replacement. The
prompt also asks for session paths only — image_view itself accepts any
image path or URL, so that part is a rule, not a check. Sub-agents keep
the tool out of their set: they gather facts, they never render.

docs/profiles.md loses the image_view omission row and gains the grant,
its raster-only limit and the accepted residual risk.

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.