record-literal constructor domains: candidates with routes, not one canonical node

[gunbai-bot]

Record-literal instantiation: candidates and routes, with its own diagnostic

When a record literal names a constructor, the check must select the field
template to instantiate. Where that selection is not available, the previous
behaviour was to pick something anyway. This models the selection explicitly
and refuses when it is not determined.

The design centre is candidates-and-routes, not a canonical Node

Returning one canonical Node for the expected type would rebuild the very bug
this repairs: it makes an unforced choice at the point where the ambiguity
lives, and then every consumer inherits that choice as if it were a fact. So
the expected type is read as a set of candidate constructor domains, each
tagged with the ExpectedTypeRoute that reached it:

route	reached via
WholeExpectedType	the expected type itself
CardinalityOptionalWrapper	inside an optional by cardinality
NominalOptionalWrapper	inside a nominal optional
CollectionElement	the element type of an expected collection
AliasTarget	the target of an alias

Candidates are deduped by owner identity, not by spelling. Selection then
folds over the domain and has exactly three outcomes — 0 owners, 1 owner, many
owners — and only the 1-owner case instantiates. Many owners refuses and
names every owner; selecting one by route order would be the absorbing
fallback (DESIGN §5), which is the failure this PR exists to close.

Why it has its own diagnostic

The decline is reported as RecordLitInstantiationUndetermined { declared, cause, span } rather than by borrowing an existing variant. #10187's body
argues the general form of this — ONE VARIANT MAY NOT ANSWER FOR TWO CAUSES —
and the rule applies to this PR's own reporting first.

The message says explicitly that it counts the check's own deficit, not a
defect in the code at that position, so the count cannot be read as an
accusation against the corpus. The cause is carried structurally as
RecordLitUnavailableCause, whose AmbiguousVariantOwners { owners } arm is
what makes the many-owner refusal name its owners rather than describe them.

Rebuilt on main

This branch was originally cut from session/still-swift-363-first-conformance
and therefore carried 54 of that PR's files, which made it unreviewable and
unlandable independently. It has been reconstructed from main and
force-pushed.

• Pre-rebuild head, retained for comparison: c85792a045950d5ae0ad59b25837ad9f10b70ed0 (tag child-pre-rebuild)
• Its only dependency on the parent was borrowing the parent's diagnostic
  variant; that is discharged by construction above, not by sequencing. This PR
  no longer depends on first()/last(): construct the declared Optional, repair the corpus that consumes it, and withdraw the decline candidate #10187 in either direction.

Evidence

• ct_record_lit_domain_selection_tests — the routes each produce a domain, and dedup is by owner identity.
• ct_instantiation_unavailable_refuses_fallback_test — a constructor reachable by two routes refuses and names every owner. Its assertion states what a 0 and a 2 would each mean, so a silent route regression reds rather than passing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HsALPpj3hERxcuCfK6Cc23

[gunbai-bot]

Superseded by #10473.

This branch was cut from session/still-swift-363-first-conformance and therefore carried 54 of
that PR's files, which made it unreviewable and unlandable independently of #10187. Its only real
dependency on the parent was borrowing OptionalNarrowingUndetermined to report its decline — and
that borrowing was the clue the dependency was accidental: an unavailable record instantiation and
an unjudgeable optional narrowing are adjacent consequences, not the same semantic fact.

#10473 is the same subject reconstructed on main, carrying its own
RecordLitInstantiationUndetermined and leaving the general narrowing concept with #10187. It has
no dependency on the parent in either direction.

The pre-rebuild head of this branch is retained at c85792a045950d5ae0ad59b25837ad9f10b70ed0 (tag
child-pre-rebuild), and this branch is left intact as a fallback.

Note for anyone following a cross-reference: finding 1 was transferred to this PR by number, and
that work now lives in #10473.

— sent from still-swift-363