…418)

The default profile generator's `@context` mapped CID v1 *predicate*
terms (`verificationMethod`, `controller`, etc.) but NOT the *class*
names. So a verificationMethod authored with the spec-example shape
`{type: "Multikey", ...}` left the bare term unexpanded:
  - in JSON-LD: a JSON-LD processor with no external context
    fetcher couldn't resolve "Multikey" to a class IRI
  - in Turtle (conneg): `expandUri("Multikey")` returned the bare
    string, N3 wrote `<Multikey>`, RFC-3986 resolved that against
    the document base — yielding `<pod>/profile/Multikey`, a
    fictional class on the pod's own host

Net: the same key on `alice.example.com` and `bob.example.com`
emitted DIFFERENT class IRIs. SPARQL queries on `?s a cid:Multikey`
missed every JSS-issued VM. VC validators couldn't recognize the
type. Same trap for `JsonWebKey`.

Fix: two flat aliases in the profile @context:

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

Why flat aliases (not pre-prefixed CURIE in the JSON-LD payload):
  - Naive JSON readers comparing `type === "Multikey"` keep
    working — readable, unchanged shape
  - JSON-LD processors expand via @context — get the canonical
    `https://www.w3.org/ns/cid/v1#Multikey`
  - Our Turtle conneg layer (which DOES respect @context per #389
    and now #416) expands and N3 writes `cid:Multikey` with the
    `cid:` prefix declared at the top of the document — any
    Turtle parser resolves it correctly
  - Matches the "JSON-LD with flat context aliases" pattern that
    consumers like LION/LOSOS rely on

Tests:
  - Profile Document: `@context` declares both `Multikey` and
    `JsonWebKey` as flat aliases mapping to the CID v1 namespace.
  - Turtle conneg: combines the production profile generator's
    @context with a synthetic VM `{type: "Multikey", ...}` and
    asserts:
      a. Turtle contains `cid:Multikey` (or full IRI form)
      b. Turtle does NOT contain bare `<Multikey>` (which would
         resolve to `<pod>/profile/Multikey`)
      c. The publicKeyMultibase value still appears (#416 didn't
         regress)

Test count: 772 → 774 in full suite.

* rdf/turtle: emit a space before `;` and `.` terminators (#419)

Match the de-facto Turtle style used in W3C 1.1 spec examples,
Apache Jena's RIOT writer, and most hand-authored Turtle in the
Solid / linked-data ecosystem: a space between the previous
token and the statement terminator.

Before:
    <s> foaf:name "Alice";
        foaf:age 30.

After:
    <s> foaf:name "Alice" ;
        foaf:age 30 .

n3.js's writer hardcodes the no-space form (`;\n    next`) and
exposes no config knob. Approach: a literal-aware post-pass on
the writer's output.

The naïve `\S;\n` → `\S ;\n` regex is unsafe — string literals
(especially triple-quoted) can contain `;\n` or `.\n` internally,
and inserting a space inside a literal would silently CHANGE the
literal's value. So:

  1. Stash every string literal AND every <IRI> into placeholders
     using a multi-character non-token-boundary sentinel
     bracketed by NULs (n3.js escapes raw NUL inside literals
     and never emits one in real Turtle output, so the sentinel
     can't collide with real content).
  2. Apply the spacing regex to the redacted output. Now `;`/`.`
     only appear as actual statement terminators because all
     literal/IRI internals are hidden.
  3. Restore placeholders.

Stash order matters — triple-quoted before single-quoted, else
`"""` looks like an empty `""` followed by `"` to the
single-quoted regex. Same for triple-vs-single apostrophe.

Tests:
  - "emits a space before ; and . terminators": positive
  - "does NOT add a space inside literals containing ; or .":
    safety regression — the post-pass MUST NOT corrupt literal
    values like `"foo;bar"`, `"has.dot"`, `"a;b.c"`.
  - "does NOT add a space inside an IRI containing ;": safety
    regression for IRIs like `<https://example.test/path;with;semis>`.

Test count: 770 → 777 in full suite (+7: 3 #419 tests + 4 #416/#417/#415 follow-ups since main).

* Address copilot pass 1 on #420 — assert by value, not by lexical form

The two safety regression tests for #419 hardcoded that N3
serializes string literals with double quotes (`"foo;bar"`)
and IRIs as `<...>`. That made them sensitive to N3 writer
formatting choices — single quotes, long-string
`"""..."""`, IRI escaping, etc. — even when the underlying
literal value would still be preserved correctly.

Fix: parse the emitted Turtle back to quads and assert the
literal/IRI VALUES, not their lexical form. The properties
the tests actually want to enforce are:
  - "foo;bar" round-trips as a literal whose value is foo;bar
    (no inserted space)
  - <https://example.test/path;with;semis> round-trips as a
    NamedNode with that exact IRI

Both are now assertion-by-value. Resilient against any future
N3 upgrade that changes quote style, IRI escaping, or the long-
string threshold.

Test count: same 777.

* Address copilot pass 2 on #420 — pin terminator presence

The "emits a space before ; and ." test asserted no offending
terminators (without preceding whitespace) but didn't assert
the terminators were actually present. If a future N3 upgrade
ever switched to the "one triple per statement, no ;
continuations" output style, the negative assertions would
pass vacuously and the test would stop exercising the spacing
behavior at all.

Fix: pin the presence of at least one ` ;` and one ` .` (with
preceding whitespace) before checking for offending forms. Now
the test fails loudly if either disappears.

Test count: same 777.

* Address copilot pass 3 on #420 — require literal space, not any whitespace

The pass-2 assertions used `\s` / `[\s]` patterns, which would
treat `\n;`, `\t;`, etc. as acceptable too. The #419 intent is
specifically a single SPACE before the terminator (matching
W3C Turtle 1.1 examples and Apache Jena's RIOT writer):
  `value ;` / `value .`

If a future N3 upgrade ever emitted `\n;` or `\t;`, the pass-2
test would have passed despite the visually-different output.

Fix: tighten the assertions to require a literal ` ;` / ` .`
(a single space). Both presence-checks and the offending-form
negative checks use ` ` (space) explicitly instead of `\s`.

Test count: same 777.