Expose read-only taxonomy access in the plugin content API

[swissky]

Problem

The plugin API currently has no way to read taxonomies. ctx.content covers collection entries (get/list), but taxonomy definitions and terms — which classify that same content — are invisible to plugins:

• A plugin can't enumerate which taxonomies exist or which collections they apply to.
• A plugin can't list the terms of a taxonomy (labels, slugs, hierarchy, descriptions/term metadata).
• A plugin can't find out which terms are assigned to a given entry.

That blocks a whole family of otherwise-sandboxable plugins: SEO tooling that emits term-aware structured data, importers/exporters that need to map terms, related-content/analytics widgets grouped by category, etc. Today the only workarounds are running natively with direct DB access, or duplicating term data into plugin storage by hand.

Proposal

Treat taxonomy reads as part of the existing content:read surface (terms classify content; no new capability, no consent-dialog churn, no lexicon/wire-contract change) and add three read-only methods to ContentAccess:

ctx.content.getTaxonomies(opts?)                       // definitions: name, label, hierarchical, collections, locale
ctx.content.getTaxonomyTerms(taxonomy, opts?)          // all terms of a taxonomy, ordered by label
ctx.content.getEntryTerms(collection, entryId, opts?)  // terms assigned to one entry (optionally scoped to a taxonomy)

All three accept an optional locale; terms come back flat with parentId (the parent's locale-agnostic translation group) so hierarchical taxonomies can be reconstructed, plus the term's data (description etc.) and translationGroup for i18n-aware plugins.

Write access is deliberately out of scope — term writes have admin-side invariants (translation groups, pivot table semantics) that shouldn't be re-exposed casually.

Implementation notes

• In-process: implement in createContentAccess (core) on top of TaxonomyRepository, so content:write contexts inherit it via the existing spread.
• Sandboxed: gate on content:read in both bridges (Cloudflare PluginBridge + sandbox-workerd bridge handler) with the same return shapes, matching the existing strict-parity approach between runners.

I have a working branch with this (incl. integration tests and docs) and can open a PR if this direction sounds right.

[ascorbic]

I think this is valuable, but I'm in two minds as to whether this would be better with a new taxonomy:read capability.

[swissky]

Agreed — I went back and forth on this too, and I think a separate capability is the better call. Terms often carry more than what content:read implies (descriptions/metadata, internal naming conventions, and the full tree including terms with no published content behind them), and keeping the consent dialog explicit about that seems worth more than saving a line in the manifest.

I've reworked #1719 accordingly: it's now a taxonomies:read capability gating a separate ctx.taxonomies accessor (getAll() / getTerms() / getEntryTerms()), with no implication from content:read/content:write. Enforced in-process and in both sandbox bridges, and the declaredAccess category, release lexicon, and consent label are wired up as well.

One naming note: I went with the plural taxonomies:read to match the existing taxonomies:read/taxonomies:manage admin permissions — happy to rename to taxonomy:read if you prefer the singular.