fix: row-count limit on $name.* expansion (10,000 rows)

[iemejia]

Split from #221 to ease review.

expand_row_set() now rejects result sets exceeding 10,000 rows to prevent unbounded SQL string allocation from large query results. Users hitting this limit should use pagination or intermediate tables instead.

Files: src/types.rs, src/lib.rs
Tests: 2 unit tests + 1 pg_test

[pinodeca]

Reviewed with Opus 4.8:

Suggestions (non-blocking)

1. Constant placement inconsistency. The codebase already defines analogous limits as module-level pub const at the top of the file — types.rs and types.rs. For discoverability and consistency, MAX_ROWSET_EXPANSION would be better as a module-level pub const alongside those rather than a function-local const buried inside expand_row_set().

2. Boundary not tested at exactly the limit. Tests cover 10,001 (reject) and 100 (accept), but not exactly 10,000. A test at == MAX_ROWSET_EXPANSION would pin down that the comparison is > (inclusive accept) and prevent an off-by-one regression.

3. The pg_test in lib.rs adds little value. As its own comment admits, it doesn't exercise the limit — it just verifies a 2-row expansion produces VALUES. That's already covered by types.rs. Consider dropping it, or making it actually assert the limit is enforced end-to-end through the DSL (which would be the unique value a pg_test adds over the plain unit tests).

4. Row count is a proxy, not the real cost. The allocation size depends on rows × columns × value width. 10,000 rows of wide/many-column data can still allocate substantially. The fixed row cap is a reasonable, simple heuristic — just flagging that it bounds row count, not total string size. Fine for this PR; worth a comment noting the rationale if you want to preempt future questions.

Verdict

Approve with minor nits. The fix does what it claims and is safe. Items 1–2 are the most worth addressing; 3–4 are optional.

[pinodeca]

LGTM