parser: parameterised type application `Name(T)` in type position blocks 27 of 28 ADR-008 specs

[gHashTag]

Measured while assembling the review package for #2168 (ADR-008). This is a
different defect from #2162 and is filed separately rather than folded into
it, because a repair exposing a previously unobservable failure is a new fact,
not a remainder of the old one.

What was measured

Binaries, both sealed with provenance captured at build time:

	commit	SHA-256
base	b92872507f6c7619acce43e5ae262b1dc9c4cbf2 (master)	836e8bc4d9a8bafa…
candidate	a33413de5c0f3bf859c715238b847c9a88fb21b9 (#2168 head)	ef99cc164c0c9d63…

28 files under specs/ contain a parameterised const declaration. After #2168:

  27  error -> error
   1  error -> ok      specs/tri/collections/array.t27

So ADR-008 acceptance is necessary but not sufficient: it unblocks exactly
one file out of twenty-eight. The other twenty-seven now fail later, on the
first construct their bodies reach.

The new failure class

The first candidate error over those 27 files:

  12  Expected LBrace, got RParen (')')
   8  Expected LBrace, got LParen ('(')
   7  Expected RBrace, got Eof ('')

The source of the first two:

fn empty() -> List(void) { ... }        // specs/tri/collections/list.t27:24
fn map(io: IO(T)) -> void { ... }       // specs/tri/io/io.t27:28

List(void) and IO(T) are type application in type position — a
parameterised type being used, where ADR-008 only settled how one is
declared. The 7 Eof cases are the same defect reported from further away:
the parser gives up mid-body and runs off the end of the file.

specs/tri/collections/array.t27 is the single file that flips precisely
because it declares ArrayView(T) and never applies a parameterised type in a
signature.

What this issue asks for

A language decision, then a parser change — in that order, as with #2162:

1. Is Name(T) in type position the target syntax for type application?
   28 files use it consistently, which is evidence of intent and not a
   specification.
2. If yes: an AST shape for it (by analogy with
   ConstDecl(name, generic_parameters, StructExpr)), plus positive and
   negative fixtures.

Not claimed

• No claim that this is the last blocking cause. 27 files fail at least here;
  what lies past it has not been measured, and a third class should be expected
  rather than assumed away.
• The corpus-wide differential for the same binary pair is clean on the measured
  349/634 = 55.0 % of specs/ (uniform 15 s timeout, 0 field-loss, 0 unknown,
  1 strict-improvement). The specs/scratch subtree is not-evaluated: at the
  same uniform timeout the run exceeded the tick budget and was stopped.

Refs #2168, #2162