one-tap ios dav provisioning

mints a dav app password, renders a configuration profile carrying both the
caldav and carddav payloads, and parks it behind a single-use five-minute token
that safari can fetch without a session.

one profile with both payloads is not a convenience: ios keys accounts by
server+username, so adding carddav separately gets folded into the existing
caldav account and contacts silently never appear.

the profile holds the password in plaintext, so it is held in memory only —
persisting it would falsify createDavAppPassword's "not stored" guarantee.

signing is opt-in via DAV_PROFILE_SIGN_CERT/_KEY/_CHAIN and off by default;
this box has no tls certificate, tls terminates upstream. signed at mint time
reading the cert from disk, so a renewal needs no restart and no hook.

the download route is registered before the /dav mount because hono matches in
registration order and the sync door's /* would otherwise demand http basic.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/servers/hono.ts

@@ -34,6 +34,7 @@ import { caldavRouter } from './api/dav/sidecar-server';
 import { memosRouter } from './api/memos/router';
 import { davSyncRouter } from './api/dav/sync-router';
 import { davRouter } from './api/dav/router';
+import { claimIosProfile } from './api/dav/ios-profile';
 import { notifyRouter } from './api/notify/router';
 import { systemMonitorRouter } from './api/system-monitor/system-monitor';
 import { activityRouter } from './api/activity/router';
@@ -104,6 +105,28 @@ honoServer.get('/api/integrations/google/callback', googleCallbackHandler);
 // DAVx5, iOS and Thunderbird authenticate with HTTP Basic on every request and have nowhere to put a
 // platform JWT, so userMiddleware would 401 them. The credential is a scoped DAV app password; see
 // api/dav/sync-router.ts.
+// The iOS profile download, registered BEFORE the /dav mount below because hono matches in registration
+// order and davSyncRouter's `/*` would otherwise demand HTTP Basic for it. Safari has no credential to
+// offer — it was handed a URL by the app and nothing else — so the one-shot token in the path IS the
+// authentication. Minted by POST /api/dav/provision/ios; see api/dav/ios-profile.ts.
+honoServer.get('/dav/provision/:file', (ctx) => {
+  const file = ctx.req.param('file');
+  const token = file.endsWith('.mobileconfig') ? file.slice(0, -'.mobileconfig'.length) : null;
+  const body = token ? claimIosProfile(token) : null;
+  // Expired, already used, or never existed — all the same 404. There is nothing useful to tell a
+  // caller who has the wrong token, and distinguishing the cases would confirm that a token once existed.
+  if (!body) return ctx.text('not found', 404);
+
+  return new Response(body as unknown as BodyInit, {
+    headers: {
+      // Mandatory. iOS identifies a configuration profile by MIME type; served as octet-stream or
+      // text/xml the file downloads and the OS does nothing with it.
+      'Content-Type': 'application/x-apple-aspen-config',
+      'Cache-Control': 'no-store',
+    },
+  });
+});
+
 honoServer.route('/dav', davSyncRouter);
 
 // Autodiscovery. This is most of what makes adding an account on a phone feel transparent instead of