feat(search)!: replace labelOnly with a lookup strategy naming its target

[ddeboer]

A labelOnly reference carried { id, label } and nothing else, so any other
field of the referent cost a second query keyed off the id just received. The
round-trip that would carry those fields is already made: the label lookup
dedupes the page's referenced IRIs, groups them by collection, fires one batched
multi_search – then keeps the label and discards the document.

labelOnly is replaced by lookup, which names its target once and carries
that target's fields. Design and rejected alternatives are in
ADR 20;
it differs from the proposal in this issue in one way, argued there: no
per-reference fields list, because two references on one target with
different lists would both want to be ‹Target›Reference with different shapes.
What is fetched is named per query instead.

{ name: 'dataset', kind: 'reference', output: true,
  ref: { strategy: 'lookup', target: 'Dataset' } }

The model

Three strategies on one axis – where a reference's fields come from:

Strategy	Carries	Surfaces as
idOnly	the IRI	a bare IRI
lookup	fields read from the target's own indexed document	a nested object
inline	fields denormalised from the parent's framing	a nested object

target names the Root Type once – the collection its fields and labels are
read from, and the name its emitted type derives from. It replaces labelSource
and ref.typeName, which for every real labelOnly were the same type
declared twice. labelSource survives only on idOnly, which emits no type but
still labels its facet buckets.

What a query asks for

SearchQuery gains a resolve projection, and the GraphQL surface builds it
from the client's selection set:

creativeWorks { items { dataset { license publisher { label } } } }

→ resolve: { dataset: { fields: ['license'], resolve: { publisher: {…} } } }

The Typesense adapter answers that with one batched round-trip per level:
each level's IRIs are deduped across the whole page, grouped by collection, and
fetched with include_fields holding exactly what the level named. A level that
cannot be fetched degrades its references to bare ids rather than failing the
search. Referents reconstruct through the same path a hit does, read through the
target's own declaration, so a consumer cannot tell a projected referent from an
inline one.

Omitted, a lookup carries its target's label alone – what every reference
carried before. Facet buckets are untouched: a bucket is a value, a count and
one label, so it stays on the cacheable label lookup.

validateQuery/assertValidQuery now take the schema and check a projection at
every level – each level's fields belong to the target the level above names,
which only the schema resolves.

Consequences worth reviewing

• No reference emits an id-plus-label object any more. With idOnly a bare
  IRI (feat(search)!: type a filter by what its field keys on #728) and labelOnly gone, labelKeyOf and the label-word agreement
  check added in feat(search): let a search type name its label field #729 have no subject left, and are removed.
• A labelOnly reference to a type nothing indexes was serving a label no
  engine could fill. The merged model cannot express that – a label needs a
  collection, so it needs a root target. Such fixtures became bare IRIs, which
  the SDL snapshot shows.
• missing-ref-type-name is narrowed to inline alone: a lookup derives its
  name from target, and an idOnly emits no type to name.
• Three coverage thresholds are re-anchored, each with a comment naming the
  branches that went.

Rebased through #741, so it carries #728, #719 and #740.

Fix #731