feat(assistant)!: no hand-off and no connector; the field searches the web (ADR 0022)

The developer decided on 23 Oct to drop the hand-off to an AI assistant
outside the app, and Claude's connector with it, in v0.19.0, the app and
the server together: build 22 raises minimumAppBuild anyway, so no app
calling the connector's endpoints uses the instance after it. An instance
is to have one way to an assistant, its operator's (ADR 0021, proposed).

The app: the field at the foot of Home, and the button in the Library, on
a studyset and while studying, search the web alone, through the engine
chosen in Settings or Android's own search, with the parts of a card the
person picks; a studyset's name and description are never offered. Gone:
the assistants a question opened in (AiAssistant, AssistantHandOff), the
switch between them and the web, Settings' choice of assistant, Connect
Claude with its route, cubit, repository and gateway, and their texts. A
settings file from before keeps the old keys until the next change of a
setting writes it anew; nothing reads them.

The server: lib/src/assistant/ (MCP, its OAuth, the five tools, connect
codes and tokens), AssistantEndpoint, the daily forgetting of the
connector's secrets (its scheduled call cancelled at start), its lines in
the deletion hook, instance.info().assistantConnectorUrl (nullable, so an
older app reads it as none), and Caddy's forwarding of /mcp, /oauth/* and
/.well-known/oauth-*. The migration drops the connector's five tables,
children first:

  DROP TABLE "assistant_token" CASCADE;       -- tokens of a connection
  DROP TABLE "assistant_grant" CASCADE;       -- OAuth codes of a connection
  DROP TABLE "assistant_connection" CASCADE;  -- a person's connected client
  DROP TABLE "assistant_connect_code" CASCADE;
  DROP TABLE "assistant_client" CASCADE;      -- OAuth clients registered

No other table references them, so CASCADE drops only their own foreign
keys. For the minute between the maintenance run and the switch, the old
server answers the connector with errors and fails to delete an account
(its hook still deletes from these tables); ADR 0022 says so.

BREAKING CHANGE: a connected Claude gets no answer from the deploy on, and
the app no longer opens a question in an AI assistant.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>

docs/adr/0022-no-hand-off-and-no-connector.md

@@ -51,7 +51,7 @@ outside the app go together.
    the connector's codes and tokens, their lines in Learn's deletion hook,
    `instance.info().assistantConnectorUrl` (nullable, so an older app reads it as none),
    and Caddy's forwarding of `/mcp`, `/oauth/*` and `/.well-known/oauth-*`. A migration
-   drops the six tables (`assistant_client`, `assistant_code`, `assistant_connect_code`,
+   drops the five tables (`assistant_client`, `assistant_connect_code`,
    `assistant_connection`, `assistant_grant`, `assistant_token`) with every connection,
    code and token in them: from the deploy on, a connected Claude gets no answer, and
    people remove the connector in Claude's settings.
@@ -67,4 +67,11 @@ outside the app go together.
   app. learn.halkyon.eu, a public instance, offers none (ADR 0021: public instances leave
   the assistant unset).
 - The instance reads payloads in one place fewer (ADR 0019's context named four).
+- **The deploy breaks the rule that migrations keep the old server working until the
+  switch**, for the minute between the maintenance run and the new server: the old one
+  then answers the connector's calls with errors, and an account deleted meanwhile (by
+  its owner, or the pruning) fails and is deleted when asked again, as the old server's
+  deletion hook still deletes from the connector's tables. Keeping the tables a release
+  longer would keep the rule, for codes and tokens nothing reads; since build 22 raises
+  `minimumAppBuild` (D3), no released app syncs with that server by then.
 - The privacy page (website repository) drops the connector and the hand-off to Lumo.