fix: methodDecl receiver type-param out-of-bounds write; decls coverage

methodDecl's receiver generic-type-parameter loop wrote to
recv_tparams[recv_tparam_count] and only checked it against
MaxTypeParams (with the wrong operator, '>' instead of '>=') AFTER the
write and the increment. A 9th receiver type parameter (e.g.
`func (s Box[A,B,C,D,E,F,G,H,I]) m() {}`) wrote past the end of the
8-element array, corrupting memory instead of producing a compile
error. Fixed by moving the bounds check (with '>=') before the write,
matching the already-correct check-before-write pattern used by the
sibling type-parameter loops in namedFuncDecl and namedTypeDecl.

Added ~70 black-box tests to compiler_test.zig closing most of
compiler_decls.zig's remaining coverage gap: zero-value/default
emission for bigint/rune/map/error/actor/interface/variant and
named-type-alias bases; interface/struct/subtype/variant/named-type
declaration-body duplicate, conflict, and MaxLocals-style ceiling
checks; malformed generic-receiver/type-param lookahead; generic-type
constraint violations and substitution in map key/val positions; a
generic type used as a plain annotation rather than a literal
expression; func-type-spec multi-return parsing and its ceilings; and
several parser edge cases (range-min-exceeds-max, incomplete hex
literal, module-qualified-type naming a function instead of a type).
compiler_decls.zig: 88.91% -> ~99% of previously-uncovered lines
closed (a handful of confirmed-dead defensive branches documented,
not chased).

Verified: zig build compiler-test (930 tests) passes; full triple-mode
suite (default, -Dpreset=stress, -Dgc_stress=true) all green when run
sequentially. Two of the three showed a transient WASM-conformance
flake when run concurrently in parallel background processes (resource
contention, not a real regression) - immediate sequential re-runs of
both were clean.

Author: ganehag