drop the jsonBody workaround — the platform parses these bodies now

this plugin read ctx.req.json() directly because registerProxiedPrefix claimed
the whole of /api/caldav, so bodyParser skipped the plugin's OWN routes and every
field read as missing.

the platform's proxy takes a proxiedSubPath now, so this claims only
/api/caldav/_officer — what the sidecar actually answers — and /passwords and
/provision/ios get their bodies the ordinary way.

verified end to end: POST /api/caldav/passwords with a label came back with the
label, and _officer/collections still reaches the sidecar.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043

api/sidecar-server.ts

@@ -11,7 +11,12 @@ import { createSidecarProxy } from '@@/sidecar/create-proxy';
 //
 // Hence one registration, two forwarders. The factory's own comment says it must never grow per-app
 // logic, so the DAV-specific half is a separate file rather than a branch inside it.
-const proxy = createSidecarProxy({ name: 'caldav', prefix: '/api/caldav' });
+// `proxiedSubPath`: this sidecar answers `_officer/*` and nothing else, so the proxy claims only that.
+//
+// Claiming the whole prefix is what stopped this plugin's OWN routes from seeing a request body —
+// `registerProxiedPrefix` tells bodyParser to leave the prefix alone, which is right for forwarded
+// traffic and wrong for `/passwords` and `/provision/ios`, which are served here.
+const proxy = createSidecarProxy({ name: 'caldav', prefix: '/api/caldav', proxiedSubPath: '/_officer' });
 
 export const caldavRouter = proxy.router;
 export const getCaldavUrl = proxy.getHttpUrl;