feat: grant a new plugin or connector to everyone by default — the admin's job is now removal, not distribution

The grant junctions (plugin_access, mcp_global_access, mcp_catalog_access)
stay deny-by-default internally, but the rows are written for you at two
moments and never again:

  — an object is CREATED: PluginManager::update_config (first toggle —
    the plugins row's birth), mcp::catalog_upsert, marketplace install,
    mcp::global_enable
  — a user is CREATED: UserManager::register_user

Who is included is the role attrs.auto_grant flag (default true, so every
role predating the attribute behaves like an adult member). The seeded
Children preset sets it to false, which is the whole reason the attribute
exists. Admins are skipped because they hold everything implicitly. The
role editor now exposes the switch as a checkbox.

New crate module: db::access_defaults (seed_new_object, seed_new_user,
set_grant_by_default). Additive columns: grant_by_default on plugins,
mcp_catalog, mcp_global_servers (INTEGER NOT NULL DEFAULT 1).

On the frontend the Roles page gets a "New extensions" column and
checklist; the user's plugin/connector rosters are unchanged. i18n:
en, fr, it.

Docs: new docs/access.md for the assistant, plus index.md cross-link.
CLAUDE.md updated with a full default-access section.

docs/access.md

@@ -0,0 +1,40 @@
+# Who can use what: plugins, connectors and roles
+
+Plugins and connectors are installed once by the admin, for the whole instance. Whether a *given person* can use one is a separate question, answered by a **grant**.
+
+## The default is open
+
+When the admin installs something new — a plugin, a globally-shared connector, or a connector from the marketplace — it is **handed to everyone straight away**. The admin's remaining job is to take it away from whoever should not have it, not to hand it out one person at a time.
+
+The same applies in the other direction: a **new user** starts out holding everything the household already uses, so a new member does not arrive to an empty account.
+
+Two things are worth knowing about how this works, because they explain behaviour that would otherwise look surprising:
+
+- **It applies at installation, not at every switch-on.** Disabling a plugin and enabling it again does *not* re-grant it to people the admin removed it from. Their decision stands.
+- **Removing access is normal and expected.** Access is taken away per person, from that person's own page: sidebar → **Users** → click the person → the **Connectors** and **Plugins** sections. Unticking a box there is the intended way to say "not for you", and nothing later puts it back.
+
+Admins never need a grant: they can use every enabled plugin and connector by construction.
+
+## Roles decide who is included
+
+Whether a role's members are included in that automatic hand-out is a property of the **role**, set in the role editor (sidebar → Roles → edit a role → **New plugins and connectors**):
+
+- **On** (the default) — anything the admin installs reaches these people immediately. This is what an adult member of the household normally wants.
+- **Off** — these people only ever get what the admin explicitly gives them, one at a time, from their own page. The **Children** role ships with this switched off, and it is the reason the setting exists: a connector installed late at night should not silently become available to a child.
+
+Turning the switch on or off changes nothing about access that has already been granted — it only decides what happens the next time something is installed, or the next time a person is added to that role.
+
+Two consequences worth mentioning to a user who runs into them:
+
+- Someone whose role has the switch **off** will see nothing new appear, ever, until the admin ticks their box. That is working as intended, not a bug.
+- Changing a person's role does **not** retroactively hand them everything installed so far. If a child is moved to an adult role, the admin still ticks the boxes on that person's page once.
+
+## What a grant actually does
+
+The three things being granted are not the same, and the difference matters when explaining it:
+
+- **A plugin grant** makes the plugin visible and usable for that person — its sidebar page, its tools, its channel (Telegram checks the grant on every incoming message). It is re-checked continuously, so removing it takes effect immediately.
+- **A shared connector grant** (one the admin runs centrally, e.g. web search) puts that connector's tools in that person's assistant.
+- **A per-user connector grant** (e.g. Gmail, WhatsApp) only authorizes the person to *set it up* — they still have to sign in with their own account. Nobody ever uses somebody else's credentials through a grant.
+
+See also: [index.md](index.md) for the plugin list, and each plugin's own page under [`plugins/`](plugins/).

docs/index.md

@@ -4,7 +4,7 @@ This folder is written for **you, the assistant**, not for the human directly. I
 
 Keep answers grounded in what's actually enabled and configured for this instance — check with the relevant tool (e.g. list installed/enabled plugins) rather than assuming everything described here is turned on. A feature documented here may not be enabled on this particular instance.
 
-This index will grow over time. Right now it covers memory, projects, system agents and plugins; more sections (agents, connectors, security groups, shared folders…) will be added later.
+This index will grow over time. Right now it covers memory, projects, system agents, access grants and plugins; more sections (agents, connectors, security groups, shared folders…) will be added later.
 
 ## Features
 
@@ -14,6 +14,7 @@ This index will grow over time. Right now it covers memory, projects, system age
 | [projects.md](projects.md) | Projects: shared folders with their own assistant chat, a live file explorer, and member sharing |
 | [system-agents.md](system-agents.md) | Background agents that run on a schedule (event triage, the two memory lints): what they watch, why they only ever report, why a run can be skipped, and their settings |
 | [settings.md](settings.md) | The admin's Config page: interface language, the compaction model picker, debug mode |
+| [access.md](access.md) | Who can use which plugin or connector: the open default, removing access per person, and the role switch that keeps children out of it |
 
 ## Plugins
 
@@ -34,7 +35,7 @@ Plugins are optional add-ons an admin can enable and configure — extra voices,
 General plugin mechanics that apply to all of them:
 
 - An admin enables/disables and configures each plugin from the **Plugins** page (sidebar → Plugins, admin-only): one card per plugin, an enable toggle, and a **Configure** button opening its settings form.
-- A plugin only becomes visible to a given user once the admin grants them access — being enabled instance-wide isn't enough by itself (Mobile Connector is the one exception: access there is the device-pairing itself, not a grant list).
-- Access is granted **per person, from that person's own page**: sidebar → Users → click the user → the **Plugins** section, right below their Connectors. So "what may this person use?" is answered in one place, for plugins and connectors together. (The plugin's own page shows the reverse view — who currently holds it — but read-only.) Admins can use every enabled plugin without being granted anything.
+- Enabling a plugin hands it to everyone straight away — except to roles that opt out of that (the Children role does). The admin then *removes* it from whoever should not have it, rather than granting it person by person. Full details in [access.md](access.md). (Mobile Connector is the one exception to the whole grant model: access there is the device-pairing itself, not a grant list.)
+- Access is changed **per person, from that person's own page**: sidebar → Users → click the user → the **Plugins** section, right below their Connectors. So "what may this person use?" is answered in one place, for plugins and connectors together. (The plugin's own page shows the reverse view — who currently holds it — but read-only.) Admins can use every enabled plugin without being granted anything.
 - A plugin with **per-user** settings (e.g. Telegram's pairing code, Honcho's memory opt-in) gives each granted user its own dedicated **sidebar page** to manage them — separate from the admin's instance-wide config.
 - A plugin can add tools the assistant calls directly (e.g. `set_secret`, `telegram_pairing`), a dedicated sidebar page, or both.