Accept message literals as list elements in annotation arguments

[trendvidia]

Closes the corpus-ahead-of-toolchain gap from #127: @meta([Item{status: 1}]) was rejected with the misleading "must be a literal or a qualified name" error because the §5.1 capture classifier refused typed message-literal list elements, making the whole argument an opaque expression capture. RFC-001 §8.1 constrains lists only by homogeneity, and the carrier's LiteralValue.literal slot represents message elements directly.

What

The root problem was representational: a typed element's type path had no home (argument-level literals carry it on AnnotationUseArg.MessageType; list elements have no argument node).

• ast: ExprDict gains an optional leading type name — ExprDict.TypeName() + Nodes.NewTypedExprDict. Only the annotation classifier attaches it; dicts from every other grammar position stay zero.
• parser: classifyMessageLiteral attaches the name to the dict it builds; classifyListLiteral accepts typed elements. Field-initializer values still keep type names out of the value grammar (nested literals type themselves from the field they initialize).
• ir (B3): classifyListElement's dict arm resolves the element's explicit type name against the use site's scope, evaluates the literal through the shared option-value evaluator (map-field rejection included), and records it keyed by the dict's braces token; new AnnotationUse.MessageLiteralElem reads it back. An untyped {...} element under an any-typed context now gets the same explicit-type-name diagnostic as the argument-level form instead of a blanket rejection. Message elements join the §8.1 homogeneity check as their own kind.
• fdp: dict elements lower to LiteralValue.literal.message — a google.protobuf.Any serialized at lowering — via the same path as argument-level literals (deduped into a messageLiteral helper). Nested lists compose.

Verification

• IR tests: bare/qualified/multi-element/nested-list acceptance (including MessageLiteralElem round-trip), untyped-element diagnostic, unresolved type name, heterogeneity.
• fdp test pins the lowered ListLiteral{elements: {literal: {message: Any}}} shape, flat and nested, down to the wire bytes.
• E2E: the issue's exact repro compiles clean; protowire's 10_literal_args.proto is unregressed (its only diagnostic is a pre-existing unused-import warning — the fixture imports annotations.proto but uses only local declarations; unrelated to this change).
• go test ./... and make lint clean.

Follow-up (protowire side, per the issue): extend 10_literal_args.proto with a message-element list and pin the lowered shape in 11_literal_carrier_golden.textproto; then the deferred @http responses parameter (RFC-001-issues §#80) can land.

Fixes #127.