Write down the tool that was built, not the one that was tabled

Secure Send shipped on 21 August and nothing outside the code caught up. The
roadmap still listed it under Deferred as "tabled", and gave as the reason that
the tools plugin is browser-only by design with get_blueprint and get_models
both empty - which stopped being true in the same day's commits that gave it a
blueprint, a table, a migration chain, a permission and a setting. A reader
following the roadmap would have concluded the feature does not exist.

The generated API docs were fine: api-inventory.json and openapi.json both
carry /api/tools/secrets, so the contract gates did their job. What was missing
was every word written for a person, and that is the half where the security
properties live.

docs/SECURE-SEND.md is the new page. The parts worth having in prose rather
than inferring from the code: that a lost secret is lost to everybody including
an administrator, which is the same property as "a compromised database yields
nothing" seen from the other side; that the 4096-character limit is the entire
server-side enforcement, because a server that cannot read what it holds cannot
have an opinion about content, so raising it turns a password tool into an
unaudited file transfer; that redeeming is a POST because preview prefetch in
chat and mail clients would otherwise spend a one-view secret before the
recipient ever sees it; and that somebody should send a link to themselves
through their own mail or chat client and confirm the key survives after the #
before a real credential goes through it, because a product that rewrites links
can strip the fragment and nothing on this side can help.

securesend_allow_guests was in the database, on a settings page, and in no
document. It is now in CONFIG.md with what it actually does - an unauthenticated
write endpoint, rate limited per address, failing closed - rather than only its
one-line description.

Also corrected along the way: site_base_url was documented as scheme + host
while the code deliberately tolerates a subpath in it, and the bundled plugin
table in PLUGINS.md had no row for tools at all.

Still missing after this: PLUGINS.md has no row for backups either.

docs/ROADMAP.md

@@ -39,20 +39,19 @@ The last big milestone before 1.0 is the legacy-ASP data import plus a productio
 - Pip-installable plugins (deferred per ADR-003 v2). Filesystem distribution stays the v1 model.
 - Event bus on `BasePlugin` (removed per ADR-001; add via new ADR if a real use case appears).
 - Frontend rebuild beyond Vue 3 + Pinia + Vite (the existing stack is fine).
-- Secret and file sharing as a Tech Tool (tabled 2026-08-21). A one-view,
-  expiring link for handing someone a credential, in place of a chat message or
-  a sticky note. NOT a Tools-plugin candidate as it stands: that plugin is
-  browser-only by design (`get_blueprint` and `get_models` are both empty) and
-  this needs storage, expiry and an audit trail, so it would be its own plugin.
-  Decisions already reached, to save rediscovering them: the sender is always
-  authenticated; a FILE recipient should be logged in too, which costs nothing
-  on an intranet-only server where everyone with the link already has an
-  account; separate permissions for sharing a secret and sharing a file, because
-  the risk classes differ; and zero-knowledge encryption is right for a
-  credential but questionable for a controlled document, where "the server
-  cannot say what was in it" is a liability rather than a feature. Export
-  control should confirm internal link sharing in writing before it carries
-  drawings or NC programs.
+- **File** sharing by expiring link. The secret half of this shipped as Secure
+  Send in the `tools` plugin ([SECURE-SEND.md](SECURE-SEND.md)); the file half
+  was dropped deliberately and stays out of scope. Dropping it removed the
+  export-control question entirely - a password is not technical data - along
+  with blob storage and the need to authenticate the recipient. What would have
+  to be settled before it comes back, so nobody rediscovers it: a FILE recipient
+  should be logged in too, which costs nothing on an intranet-only server where
+  everyone with the link already has an account; sharing a file wants its own
+  permission separate from sharing a secret, because the risk classes differ;
+  and zero-knowledge encryption is right for a credential but questionable for a
+  controlled document, where "the server cannot say what was in it" is a
+  liability rather than a feature. Export control should confirm internal link
+  sharing in writing before anything here carries drawings or NC programs.
 
 ## What 1.0.0 means