parser: let a parameter destructure a tuple

[simontreanor]

Dogfooding finding #4 (see #34).

fun (t, sq) -> … did not parse, so anything folding over pairs needed a named helper wrapping a match. The dogfooded game had five such one-line functions existing only to unpack a tuple.

Param now carries the pattern it binds rather than a name, and the parser admits the shapes that cannot fail to match: a name, _, or a tuple of those, nested. Refutable shapes are rejected where written, naming what was seen (a constructor pattern, a record pattern, …), since a parameter has nowhere to fail to.

Two decisions worth review:

• Only a parenthesized parameter takes the pattern grammar. A bare uppercase identifier stays a parameter name, so let f Some x = … keeps meaning two parameters instead of silently becoming one constructor pattern. Test pins this.
• _ as a parameter comes along for free and is new: the lexer's _ was never an identifier, so it could not be written before. A lone _ parameter emits as Python's own _; a second one takes a synthetic name, since duplicate argument names are a SyntaxError.

Each phase reuses existing machinery: typing binds the pattern through bind_pattern (the match-arm path), the LSP walks it through pattern_vars for binder spans, and lowering unpacks it on the body's first line, after any global/nonlocal declarations, one statement per nesting level via a new PyStmt::UnpackAssign:

def tileScore(_pf_arg0):
    t, sq = _pf_arg0
    return t * sq

def nested(_pf_arg0):          # let nested ((a, b), c) = …
    _pf_arg0_0, c = _pf_arg0
    a, b = _pf_arg0_0

Python 3 removed tuple parameters and a Python lambda cannot hold a statement, so a destructuring lambda lowers to a named def however simple its body is. Caught that one from wrong emitted code (lambda acc, _pf_arg1: acc + a * b, with a and b free) rather than from a test, so there is now a test asserting no lambda is emitted for that shape.

Soundness note: the fold-to-loop pass rejects a folder with a destructuring parameter. It rewrites by substituting parameter names and there is no single name to substitute, so such a fold falls through to the byte-identical _pf_fold lowering.

Not covered, deliberately: record patterns in parameters (fun (Cell { letter }) -> …). They are irrefutable and would fit, but they need attribute-reading lowering rather than tuple unpacking, and #37 (field access by the base's type) removes most of the pressure for them. Happy to add if you'd rather.

Tests: 8 roundtrip programs, 7 rejection cases plus the let f Some x shape, 4 typecheck cases, 4 lowering assertions and an e2e round trip. Full suite, clippy and fmt clean.