After #388 the IDP emits CID-v1-shaped card.jsonld for newly created accounts, but existing pods still have their pre-#388 profile sitting on disk and never get rewritten. As a result, accounts created before the v0.0.169 rollout fail the LWS-CID profile-shape check even though the running JSS is fully capable of producing the new shape.

Confirmed live: https://melvin.solid.social/profile/card.jsonld is still the old foaf+solid-only document; https://test.solid.social/profile/card.jsonld (created post-rollout) is the new CID-v1-shaped one.

Surfaced by doctor: drop the WebID URL into https://jss.live/doctor/ and you get a red "@context declares CID v1 vocabulary" with "No CID v1 terms found" for any pre-rollout account.

Options

1. One-shot migration on next pod open / write — when the IDP next touches a profile, re-render through the post-profile: emit CID v1 controller + prep verificationMethod context (#386 Phase A) #388 generator and persist. Lazy, no downtime, but profiles never touched stay stale forever.
2. Boot-time backfill — script that walks DATA_ROOT/*/profile/card.jsonld and rewrites any document that lacks the CID context. Run once during deploy. Keeps user-added triples (which we'd want to merge, not overwrite).
3. Dynamic generation on read — never persist the profile to disk at all; always generate on each GET. Sidesteps the migration entirely but changes the storage contract and breaks anyone who has hand-edited the file.

Option 2 (with merge of any user-added triples) seems most honest. Option 1 is fine as a fallback for anything 2 misses.

Acceptance

• After running the migration, https://melvin.solid.social/profile/card.jsonld returns the CID-v1-shaped document.
• Doctor's @context check goes from red to green for previously-stale pods.
• User-added triples (foaf:knows, custom name fields, etc.) are preserved.

Refs #386, #388.