Rename the identifiers that carried the upstream name

Everything clients, users and operators meet now carries the fork's name,
with no aliases (SPEC.md §2.4, changed here from "protocol identifiers
stay"):

- JMAP: upstream's registry capability is urn:inbuxa:jmap:registry, beside
  the fork's own urn:inbuxa:jmap.
- WebDAV lock and sync tokens are urn:inbuxa:dav*; clients resync once.
- Sieve: vnd.inbuxa.while and vnd.inbuxa.expressions. sieve-rs spells these
  into its compiler, so it's vendored (vendor/sieve-rs, 0.7.3) and patched in;
  a unit test fails if Cargo.lock ever moves past the vendored copy. The
  trusted runtime now names itself too, rather than answering sieve-rs's
  default.
- The web interface's OAuth client is inbuxa-webui. On every start the old
  stalwart-webui client is removed and any application naming it is moved
  over.
- The spam filter's blobs are INBUXA_SPAM_*; every start moves any left
  under the old keys, so a trained model survives.
- SQL stores and log files default to inbuxa, in the code and in the
  schema served to the admin (checksum regenerated).
- Settings are INBUXA_* only. A STALWART_* variable that's set where its
  INBUXA_* one isn't stops the server at startup, naming it.
- The version-upgrade messages link docs.inbuxa.org's migration page, and
  the OpenAPI description, smtp crate metadata and web-push test fixtures
  lose the name.

Kept on purpose, allowlisted with reasons: the OAuth key-derivation
contexts (renaming them would end every session and invalidate every
sealed client id) and the hashed application prefix.

Also fixes a latent start-up failure: ensure_client updated an existing
first-party client with a revision of 0, which the registry's assertion
never matches, so adding a redirect URI or changing the webmail secret
failed start-up. And the principal session test now expects
legacyProtocols (C-1, added 2026-09-21), which it had missed.

Tested: the server builds without warnings; common's 106 unit tests,
including the vendoring check; a new integration test for the two
start-up migrations; and the webdav, jmap, imap and SMTP Sieve suites.

api/v1/openapi.yml

@@ -1,8 +1,8 @@
 openapi: 3.0.3
 info:
-  title: Stalwart Management API
+  title: inbuxa Management API
   description: |
-    REST Management API for Stalwart server. These endpoints are helpers
+    REST Management API for the inbuxa server. These endpoints are helpers
     that complement the JMAP API — most of the server's configuration and data
     is managed via JMAP (see `POST /jmap/`). The endpoints documented here cover
     interactive login, account introspection, configuration schema retrieval and
@@ -12,11 +12,11 @@ info:
     name: AGPL-3.0-only OR LicenseRef-SEL
 servers:
   - url: https://{host}
-    description: Stalwart server
+    description: inbuxa server
     variables:
       host:
         default: mail.example.com
-        description: The hostname of Stalwart server
+        description: The hostname of the inbuxa server
 security:
   - bearerAuth: []
   - basicAuth: []
@@ -154,7 +154,7 @@ paths:
       operationId: getSchema
       summary: Return the configuration schema at a specific hash
       description: |
-        Returns the JSON Schema describing the full Stalwart configuration tree.
+        Returns the JSON Schema describing the full inbuxa configuration tree.
         The response is always gzip-encoded (`Content-Encoding: gzip`) and served
         with an immutable cache policy — the schema for a given hash never
         changes. If the hash does not match the server's current schema, the
@@ -183,7 +183,7 @@ paths:
             application/json:
               schema:
                 type: object
-                description: JSON Schema document describing Stalwart config
+                description: JSON Schema document describing inbuxa config
                 additionalProperties: true
         '302':
           description: Redirect to the current schema URL when the hash is stale
@@ -395,7 +395,7 @@ components:
         WWW-Authenticate:
           schema:
             type: string
-            example: Bearer realm="Stalwart Server"
+            example: Bearer realm="INBUXA Server"
       content:
         application/problem+json:
           schema: