LinkField Link/SiteTreeLink records have no content-api write surface at all

[jsirish]

Context

Same source as #115 — mining a client production-restructure project's Epic A retrospective. LinkField
records were the second-most common reason a BuildTask was needed instead of content-api.

The gap

SilverStripe\LinkField\Models\Link and its subclasses (SiteTreeLink, EmailLink,
ExternalLink, etc.) have zero content-api surface — not even a read path via the schema/records
endpoints, as far as this project's exploration found. Every nav link, footer link, CTA card
link, or hero-slide button link needs a BuildTask:

// Temp05NavTask.php — utility nav / footer nav
$link = SiteTreeLink::create();
$link->LinkText = $add['title'];
$link->PageID = $page->ID;
$link->OwnerID = $aboutGroup->ID;
$link->OwnerClass = NavigationGroup::class;
$link->OwnerRelation = 'NavigationLinks';
$link->write();

This compounds with #115 (Elemental content) — most LinkField records on a typical Elemental
site are owned by an Element (a CTA card's link, a hero slide's link), so fixing #115 alone
still leaves the link itself unreachable.

Ask

Expose Link/SiteTreeLink to api_writable_fields/api_writable_relations the same way any
polymorphic-owner DataObject is exposed. The OwnerID/OwnerClass/OwnerRelation polymorphic
pattern is presumably the main design question — worth scoping whether a generic polymorphic-owner
write path is a bigger ask than this issue alone, or whether Link can just declare
content_api_access like any other class and be written via OwnerID/OwnerClass as plain
writable fields, same as any other has_one FK.

[jsirish]

Re-scoping per the 2026-08-06 process audit — the module already ships half of this

The audit found the module ships _config/linkfield.yml + LinkTransformer: has_one-to-Link writes ({"type":"SiteTreeLink","pageId":…}) are a first-class, idempotent, documented feature (docs/en/06_write-payloads.md). Retargeting a card's ElementLink — a headline example when this was filed — was blocked only because the owning element class wasn't registered (see #115's re-scope), not because Link writes don't exist.

What genuinely remains:

1. Inline create for has_many-owned links — applyRelations() items are id/externalId references only; there is no way to create links owned via has_many (SiteConfig.UtilityLinks, NavigationGroup.NavigationLinks) through the API. This forced Temp05NavTask into existence.
2. The polymorphic Owner* triple (OwnerID/OwnerClass/OwnerRelation) needs explicit design for created links.
3. Direct Link/SiteTreeLink CRUD registration defaults — registerable like any class today, but ship it in the linkfield exposure pack so it's config, not discovery.

[jsirish]

Same cross-link as #115 - our internal essentials-content-api-setup skill now points at this re-scoping comment rather than the original "no write surface at all" framing.