Publish the ARD base context at /context/v1

[rvguha]

Problem

§4.1 of the spec says term IRIs come from a base context served at https://agenticresourcediscovery.org/context/v1, which a conformant consumer applies as the JSON-LD expandContext.

That URL currently returns 404 (the docs-site HTML shell). It's the one normative reference an ARD entry makes back to this site, so anyone reviewing a published entry and clicking through hits a dead link.

The context file itself landed in the canonical repo with ards-project/ard-spec#70 — it just isn't served anywhere.

Approach

Follows the pattern hooks/spec_from_canonical.py already establishes: the context lives only in ards-project/ard-spec (spec/schemas/ard.context.jsonld) and is fetched at build time, so this repo never holds a second copy that can drift from canonical.

Verified locally — the published file is byte-identical to canonical, parses, and works as an expandContext:

byte-identical to canonical: True
terms: 17 | @vocab: https://agenticresourcediscovery.org/ns#

expanded:
  https://agenticresourcediscovery.org/ns#identifier
  https://agenticresourcediscovery.org/ns#displayName
  https://example.org/okf#taxonomy        ← a second namespace still resolves

Two decisions worth reviewing

1. Content-Type — the bare path may not satisfy strict processors.

Static hosting assigns Content-Type from the file extension, and GitHub Pages offers no way to set headers. An extensionless file is served as application/octet-stream, while the JSON-LD 1.1 API requires a remote context to arrive as application/ld+json, application/json, or a +json type — a strict processor rejects anything else.

So /context/v1 resolves and reads correctly, but a strict consumer that dereferences it may still refuse it. This PR also publishes /context/v1.jsonld with identical bytes, which gives those consumers a URL that works today.

Making the bare path fully correct needs either a host that can set headers, or a spec that names the suffixed URL. Both are spec/infra decisions rather than build ones, so I've left them alone — happy to follow up whichever way you prefer.

2. A fetch failure publishes nothing.

spec_from_canonical.py falls back to a placeholder page, which is right for prose a human reads. It would be wrong here: a partial or unparseable document served at a context URL is worse than a 404, because a consumer would apply it and expand every term incorrectly. On failure this logs a warning and leaves the URL 404ing.

The fetched document is also parsed and checked for @context before publishing, so an HTML error body arriving with a 200 can't be served as the context.

🤖 Generated with Claude Code

[mindpower]

LGTM.