lowering: accept a destructuring element parameter in the fold-loop pass

[simontreanor]

What

The in-place fold pass (DESIGN.md §5.1) rejected any folder whose element parameter was a pattern rather than a name, so List.fold (fun m (p, l) -> Map.add p l m) Map.empty steps fell back to _pf_fold (a fresh copy per step) and went quadratic, while the fst/snd spelling of the same folder was linear.

Only the accumulator parameter is substituted by name; the element parameter is just the loop target. This PR accepts any irrefutable element pattern:

• PyStmt::For now carries a PyForTarget (a name or a nested tuple of names), so a tuple element emits Python's own header: for (p, l) in steps: / for (a, (b, c)) in xs: / for (p, _) in steps:.
• Any other irrefutable shape binds a fresh temp and unpacks on the first line of the loop body through the existing unpack_into_as (the same machinery a destructuring def parameter uses). Not reachable from the parser today, which admits only names, wildcards and tuples as parameters, but the emit path is covered by a unit test.
• The pattern's bound names count as body binders for the P8 collision check, so let clash p = … List.fold (fun m (p, l) -> …) still falls back.
• The accumulator parameter (params[0]) keeps its existing name-only rule; PYFUN_NO_FOLD_OPT and the rejected path are byte-identical.

Top-level and block-local named folders (let add m (p, l) = …) get the same treatment, and it composes with the tuple accumulator.

Tests

tests/compile.rs: lambda, top-level named, block-local named, nested tuple, wildcard, tuple-accumulator composition, the P8 clash fallback, a destructuring accumulator still falling back, and an e2e check that the destructuring and fst/snd spellings both take the loop path and agree. src/lowering/fold_loop.rs: unit tests for loop_target.

cargo test, cargo clippy --all-targets, cargo fmt --check all clean.

Closes #85