profile: declare Multikey/JsonWebKey class names in @context (#417) - #418

Closes #417. Builds on #416 (Turtle converter accepts id/type aliases on nested objects).

Problem

The server-default profile's @context mapped CID v1 predicates (verificationMethod, controller, publicKeyMultibase, etc.) but NOT the class names Multikey and JsonWebKey. An app PATCHing in a verificationMethod with the spec-example shape {type: "Multikey", ...} triggered:

<.../#nostr-key-1> a <Multikey> ;
    cid:controller <.../#me> ;
    cid:publicKeyMultibase "fe701..." .

Per RFC 3986, <Multikey> resolves against the document base — yielding <pod>/profile/Multikey, a fictional class on the pod's own host. Same key on alice.example.com and bob.example.com emitted DIFFERENT class IRIs. VC validators / SPARQL queries against cid:Multikey missed every JSS-issued VM.

Fix

Two flat aliases added to @context in src/webid/profile.js:

"Multikey":   "cid:Multikey",
"JsonWebKey": "cid:JsonWebKey",

The flat-alias shape (vs. pre-prefixed CURIE in the payload) preserves three properties:

• Naive JSON consumers comparing type === "Multikey" keep working — payload shape unchanged
• JSON-LD processors expand via @context to the canonical https://www.w3.org/ns/cid/v1#Multikey
• Turtle conneg (post-rdf/turtle: accept JSON-LD id/type aliases on nested objects (#415) #416) respects @context and emits cid:Multikey with the cid: prefix declared at the top — any Turtle parser resolves it to the canonical IRI

This matches the "JSON-LD with flat context aliases" pattern that consumers like LOSOS / LION rely on.

Test plan

• Unit: @context declares both Multikey and JsonWebKey as flat aliases mapping to the CID v1 namespace
• Unit (Turtle conneg): combines the production profile generator's @context with a synthetic VM {type: "Multikey", ...} and asserts:
  • Turtle contains cid:Multikey (or full IRI form)
  • Turtle does NOT contain bare <Multikey> (would resolve to fictional <pod>/profile/Multikey)
  • publicKeyMultibase value still appears (rdf/turtle: accept JSON-LD id/type aliases on nested objects (#415) #416 didn't regress)
• Full suite: 772 → 774 pass

Migration note

Existing profiles authored before this change still have the old @context without the class aliases. Their conneg-converted Turtle will continue to emit bare <Multikey> until the profile is re-emitted (e.g. via a profile-rewrite migration or simply a future PUT through this updated emitter). New pods + profiles created via JSS get the fix automatically.

For the live test pod on solid.social specifically, I'll patch its @context manually after this lands so its /.well-known/did/nostr/... and Turtle conneg paths produce clean class IRIs without waiting for a re-emit.