Fix: single-field/no-comma typedef struct, and anonymous struct as a function-type segment

[mallyskies]

Depends on #81 (fix/switch-case-multiple-statements) — based on its tip.

Two related gaps in $.structure_type's reach, found:

1. typedef_declaration's RHS still listed $.block as a choice alongside $.structure_type (a leftover from before $.structure_type existed as its own rule) -- a bare identifier : expression is also a valid one-statement $.block via $.pair's low-precedence bare-literal alternative, so a single-field, no-trailing-comma struct (typedef X = { f:T }) hard-errored -- $.block and $.structure_type both matched the same tokens, and tree-sitter's own conflict analysis called it an "unnecessary conflict" (no tie to break) while it still errored at runtime. Fix: replaced $.block with a new dedicated $._structure_class_body rule restricted to exactly var/function member declarations (aliased to $.block so existing consumers/tests see the same node type), which structurally can't overlap with $.structure_type's bare shape.

2. $.type had no $.structure_type alternative at all, so an anonymous struct could only appear where a call site hand-rolled its own choice($.type, $.structure_type) workaround. cb:String->{}->Void hard-errored everywhere except that one call site. Fix: added $.structure_type as a bare $.type choice, so every $.type slot gets anonymous-struct support for free.

   This creates one new, genuine ambiguity, deliberately resolved rather than left to chance. (name: {}) can be built two structurally valid ways from the exact same tokens: as a runtime type-check (name checked against the empty-struct type {}) or as a parenthesized, bare pair expression (name mapped to an empty object value {}). Removing the [$.object, $.structure_type] entry from conflicts and regenerating confirms tree-sitter treats this as a live, unresolved conflict — not a false positive — and names exactly these two rules as the competing interpretations. Resolved with prec.dynamic(1) on structure_type, which only breaks the tie once the GLR parser has already forked on a genuinely ambiguous input, rather than a static prec() bump, which changes the shift/reduce table globally and (confirmed by testing) breaks unrelated multi-arrow $.function_type chains like String->{}->Void elsewhere in the grammar.

   Concretely, the tie-break means: (name: {}) now always parses as the type-check reading (structure_type). The pair-expression reading (name paired with an empty object) becomes unreachable through this specific ambiguous shape — confirmed by temporarily reversing the tie-break and observing the parser fall back to exactly that tree. This is a narrow, low-risk trade-off: a bare parenthesized pair with an empty-object value is a vanishingly rare thing to write in real code (pairs normally appear inside {}/[] literal delimiters, not floating alone in parens).

Known limitation, not fixed here: a $.structure_type segment that ISN'T the last segment of a $.function_type chain still fails to extend into a further right-nested function_type when the chain's outer context is a variable/field type or a function's return type. Documented in $.function_type's comment and locked in by a corpus test so a future fix is a deliberate, visible change rather than a silent one.

Verified: 234/234 corpus tests pass (4 new).

[mallyskies]

Thanks!