Add a `--provision-keys` flag (and `provisionKeys: true` body field for
POST /.pods) that, on pod creation, generates a Schnorr secp256k1
keypair and writes it as a W3C CID v1.0 Multikey document to
<pod>/private/privkey.jsonld. Off by default — keys-on-disk is a
security tradeoff and we want operators to opt in deliberately.

The single key is intended to serve as: a Solid signing identity, a
Nostr identity (same curve), and a did:nostr DID controller (Phase 2).
One CLI flag → pod-resident self-sovereign identity ready for both
Solid and Nostr / agentic use cases.

Phase 1 scope (per #437 design resolutions):

- Encoding: f-form Multikey (multibase `f` + multicodec varint +
  payload, base16-lower) — matches src/auth/nostr-keys.js's existing
  decoder, no new deps. Round-trips through decodeFFormSecp256k1.
- Controller: pod owner WebID. Phase 2 will swap in did:nostr once
  the resolver lands; the document is self-consistent at every phase.
- File mode: 0o600 on POSIX. WAC restricts HTTP access; the file mode
  blocks a separate exposure class (other unix users on the box,
  backups that don't preserve permissions). Defence-in-depth, not a
  replacement for FDE / OS keyring.
- No `nostr` extension block (no nsec/npub). Bech32 npub is a
  one-line derivation in any Nostr-aware tool; including it would
  double the secret-on-disk surface for log/error/dump leaks.
- Opt-in: defaulting on would silently ship a plaintext secret on
  every `jss start --single-user`. Visible choice required.
- HTTP response surfaces `ownerKey: { keyDocument, publicKeyMultibase }`
  on success — never the secret. Single-user banner logs the same and
  a prominent BACK UP warning.

Files:

- src/keys/provision.js — generator + Multikey serializer + the
  decideRevealForRegisterStatus-style pure helpers for unit testing.
- src/handlers/container.js — createPodStructure accepts
  { provisionKeys: true }; handleCreatePod reads provisionKeys body
  field; response includes the key info when set.
- src/server.js — createRootPodStructure accepts the option via the
  new provisionKeysEnabled local; single-user onReady captures the
  key result and logs the public side + backup warning.
- src/storage/filesystem.js — write() takes an optional { mode } so
  callers can request 0o600 without a separate chmod call. Backward
  compatible (every existing caller passes nothing, mode no-ops).
- src/config.js — defaults.provisionKeys, BOOLEAN_KEYS membership,
  JSS_PROVISION_KEYS env var mapping.
- bin/jss.js — --provision-keys / --no-provision-keys CLI options,
  threaded through to createServer.
- docs/provision-keys.md — usage, file format, threat model with the
  filesystem-protection table, credible-exit framing for the upgrade
  path, backup instructions.
- test/keys-provision.test.js — 13 unit tests: keypair generation
  (sign/verify roundtrip, uniqueness), encoder fixed vectors,
  decoder round-trip via src/auth/nostr-keys, JSON-LD shape, no
  nostr block, error cases.
- test/keys-provision-integration.test.js — 9 integration tests:
  POST /.pods writes the file + Multikey shape, file mode is 0o600
  on POSIX, WAC blocks unauthenticated reads + serves authenticated
  owner, opt-in respected (no flag, false, string "true"), direct
  createPodStructure call returns ownerKey only when option set.

840/840 tests pass.

Out of scope (deferred to later phases per #437):
- did:nostr controller (Phase 2)
- WebID profile auto-population with the public key (Phase 2)
- --key-passphrase / scrypt+aesgcm wrap (Phase 3)
- BIP-39 seed phrase derivation (Phase 3)
- Hardware wallets / KMS / encrypted-at-rest (Phase 4)

Six small but real fixes from the first review pass.

1. storage.write created the file with the process umask (often 0644)
   and only then chmod'd to the requested mode. Race window where
   another local process could read freshly created secret material
   before chmod ran. Pass `mode` to fs.writeFile at create time so
   the file is *born* with the right perms; keep the chmod afterward
   as belt-and-braces for the overwrite case (Node only honours mode
   at create time, not on overwrite).
2. createRootPodStructure's docstring said the secret was "never
   returned", but the returned ownerKey object includes secretHex
   and secretKeyMultibase. Tightened the doc to match reality —
   "callers must not log the secret" — and noted why we keep the
   internal representation full (tests, future one-shot signing).
3. Single-user onReady built the same `keyPath` string in both
   branches of an isRootPod ternary. Collapsed to one expression
   (podUri already carries the trailing slash + name segment).
4. docs/provision-keys.md intro referenced "#427 / #437" — but #427
   is the unrelated ACL-portability umbrella. Just #437.
5. docs backup example only showed the root-pod path. Added the
   named-pod variants for both the HTTP curl backup and the on-disk
   cp backup, since the named-pod layout is the multi-user case.
6. Updated storage.write JSDoc to document the new `options.mode`
   argument with the rationale.

840/840 tests pass.

Address Copilot pickup on #442. --public bypasses WAC and grants
unauthenticated access to every resource — including any
/private/privkey.jsonld we'd just written. The two flags are
explicitly incompatible; refuse the combination at every entry point
so the operator hits the contradiction immediately rather than by
reading a leaked key from logs or the public web.

- New assertProvisionKeysCompatible({ provisionKeys, isPublic })
  exported from src/keys/provision.js. Throws with a clear error
  message naming both flags and the WAC bypass.
- src/server.js calls the assertion at server-create time. A
  `jss start --single-user --provision-keys --public` invocation
  now fails to start instead of silently writing a public secret.
- src/handlers/container.js handleCreatePod returns HTTP 400 when
  request.config?.public is true and provisionKeys: true is sent.
  Pod is not created; error explains why.
- docs/provision-keys.md gains an "Incompatible with --public"
  section spelling out both refusal points.
- 4 new unit tests for the assertion (full truth table).
- 1 new HTTP integration test exercising the 400 path on a
  --public test server.
- 1 new createServer-throw test asserting the synchronous refusal
  on construction.

847/847 tests pass.

Three Copilot pickups on #442 (round 3).

1. handleCreatePod imported assertProvisionKeysCompatible last round
   but was still doing the public-mode check inline — dead import.
   Switch the call site to the helper and convert the throw into a
   400 response. Single source of truth for the error message,
   shared with createServer's startup-time check.

2. createPodStructure called storage.write() for the secret key but
   ignored the boolean return. storage.write returns false (without
   throwing) on failure, so a write that silently failed would have
   left the pod in a state where the response advertised an
   `ownerKey` against an on-disk file that didn't exist. Throw on
   `!ok` so the existing handleCreatePod cleanup path (storage.remove
   + 500) runs.

3. createRootPodStructure had the same gap: single-user startup
   could log "Provisioned Schnorr secp256k1 owner key" against a
   missing file. Throw on `!ok` so the start fails loud — the
   operator explicitly asked for --provision-keys, a silent failure
   would surface only when they later tried to read the key.

847/847 tests pass.

Two more Copilot pickups on #442.

1. createPodStructure activated key provisioning on any truthy
   options.provisionKeys — inconsistent with handleCreatePod's
   strict === true check on the request body. A misconfigured
   direct caller passing 'true' / 1 / etc. would have silently
   provisioned a plaintext secret. Match the HTTP-side behaviour:
   strict === true at both entry points. New regression test asserts
   string 'true' doesn't trigger at the direct entry.

2. storage.write JSDoc said the chmod was a 'No-op on Windows', but
   the implementation always attempts chmod regardless of platform.
   Update the doc to reflect the actual behaviour: chmod is best-
   effort everywhere, NTFS approximates POSIX modes coarsely (read-
   only flag based on owner perms), callers should not rely on it
   for cross-platform secrecy. Inline comment also clarified.

848/848 tests pass.

Address Copilot pickup on #442. provisionKeysEnabled was derived as
options.provisionKeys ?? false, which preserves truthy non-booleans.
Combined with the strict === true check inside createPodStructure
(named-pod path), this left the two pod shapes behaving differently
for the same misconfigured input:

  options: { provisionKeys: 'true' }
  → root pod: if (provisionKeysEnabled) → truthy string → provisions
  → named pod: createPodStructure({ provisionKeys: 'true' }) →
              strict === true → does NOT provision

Coerce to a strict boolean at the createServer boundary so both
paths see the same value. A misconfigured `'true'` / `1` / etc. now
falls through to false at the entry point and the operator gets the
no-op behaviour on both pod shapes.

848/848 tests pass.