Generic type APPLICATION (Name(T) in a type position) is rejected; 20 library specs, needs a language decision

[gHashTag]

Split out of #2162 and deliberately NOT counted in its statistics.

#2162 is about the DECLARATION pub const Name(T) = struct { ... }, fixed in
branch w699-generic-const-decl (ADR-008). This issue is about the APPLICATION
of such a type: using Name(T) in a type position.

Measured

Baseline binary /tmp/t27c.m2162base vs candidate /tmp/t27c.m2162fix, library
corpus (634 specs, specs minus specs/scratch), 12 s threshold:

• 27 files had their first parse error move LATER after the declaration fix. The
  new first error is the application form.
• Of the 27 files in the error signature Expected LBrace, got LParen/RParen,
  the failing line contains a generic type application in 18; a newtype form
  struct Name(str); in 5 (account/repo.t27, account/schema.t27,
  auth/config.t27, file/watcher.t27, shell/process.t27 -- possibly a
  separate question); and something else in 2 (math/pellis_precision_verify.t27
  line 88 for i in 0..len(s) {, runtime/execute.t27 line 238, a function-type
  parameter resolve_fn: fn(TaskResult) void).
• Independent count over the corpus: 8 files use return-position application with
  letter parameters, 30 use parameter-position, union of declaration and
  application = 34 files.

Representative failing lines:

specs/tri/collections/list.t27:24     fn empty() -> List(void) {
specs/tri/collections/map.t27:23      fn empty() -> Map(K, V) {
specs/tri/collections/either.t27:34   fn is_left(either: Either(L, R)) -> void {
specs/tri/collections/maybe.t27:28    fn bind(maybe: Maybe(T)) -> void {
specs/tri/collections/set.t27:27      fn add(set: *HashSet(T)) -> void {
specs/tri/graph/graph.t27:33          fn add_node(graph: *Graph(T)) -> void {

Note that -> P(2), -> Z(1) and -> N(0) parse fine today. Those are a
different construct (numeric argument), so the parser is not uniformly rejecting
Ident(...) in return position.

What this issue is NOT

It is not a claim that the parser is wrong. Consistent use across 20 files is
evidence of intent, not a specification. Accepting the application form is a
language decision, exactly as the declaration form was, and it needs the same
treatment: an ADR fixing the AST contract BEFORE any parser edit -- including how
Name(T) in a type position is distinguished from a call expression, and whether
*Name(T) binds as pointer-to-application.

Until that decision exists, these 20 files stay classified
unrelated-parse-failure and are not attributed to #2162.

Refs #2162