IRI-valued quote URL aliases are dropped during JSON-LD parsing

[dahlia]

Description

Fedify 2.3.6 throws TypeError: Invalid URL when it parses a valid ActivityStreams Note whose JSON-LD context declares _misskey_quote or quoteUri as an IRI-valued property. Current main no longer throws because parseIri() rejects the missing value, but Object.fromJsonLd() silently drops the quote URL and returns null from quoteUrl.

This occurs with real Notes from Misskey-compatible servers. The following reduced document reproduces the same expanded JSON-LD shape without depending on a remote server:

import { Object } from "@fedify/vocab";

const object = await Object.fromJsonLd({
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "misskey": "https://misskey-hub.net/ns#",
      "_misskey_quote": {
        "@id": "misskey:_misskey_quote",
        "@type": "@id"
      }
    }
  ],
  "id": "https://example.com/notes/1",
  "type": "Note",
  "_misskey_quote": "https://example.com/notes/quoted"
});

console.log(object.quoteUrl);

Expected output:

https://example.com/notes/quoted

Fedify 2.3.6 instead throws while constructing a URL from undefined. At e682b83, it prints null.

Cause

The JSON-LD expansion of an @type: "@id" term is an object with an @id member. The generated decoder in packages/vocab/src/vocab.ts reads v["@value"] for quoteUrl and its redundant aliases, so it never reads that IRI. The decoder comes from the fedify:url entry in packages/vocab-tools/src/type.ts. The existing Note.quoteUrl coverage in packages/vocab/src/vocab.test.ts defines the aliases as plain terms, which expand to @value and do not exercise the IRI-valued form used by affected servers.

Expected behavior

quoteUrl should accept the @id form produced by IRI-valued _misskey_quote and quoteUri contexts, while keeping support for the current @value form. A regression test should cover an alias declared with @type: "@id".