Build large test payloads lazily

[danielfrankcom]

This change builds large test payloads lazily to avoid GitHub runner resource limits.

Size limit and large collection tests embedded multi-megabyte strings, byte buffers, and document lists directly in their parametrized data. pytest keeps every parameter for the whole session and each xdist worker holds its own copy, so this pinned ~2.8 GiB per worker and pushed the replica-set CI job into swap space.

• Added lazy(build), which defers construction and is typed as the built value so field types are unchanged.
• The framework materializes lazy values where it consumes them, so each value is built while its test runs and freed after.
• Per-worker collection memory should drop from ~2.8 GiB to ~0.5 GiB.
• A collection-time guardrail fails any test whose parametrized data exceeds 1 MB, so there are no future regressions.

[danielfrankcom]

Based on the logs for this CI run and an earlier run in #645, this change seems to significantly improve the situation:

Metric	This run (lazy)	Before the fix
Peak host memory	10,012 / 15,988 MB (63%)	15,236 / 15,989 MB (95%)
Peak swap	0 MB (never touched swap)	~3,071 MB

[documentdb-triage-tool]

🤖 Auto-triaged by documentdb-triage-tool.

Applied: compatibility test, enhancement
Project fields suggested: Component test-coverage · Priority P1 · Effort XL · Status Needs Review
Confidence: 0.85 (mixed)

Reasoning

component from path globs (test-coverage, test-framework, ci); effort from diff stats (498+218 LOC, 49 files); LLM: Fixes a CI memory exhaustion issue (~2.8 GiB per worker pushing jobs into swap) by lazily building large test payloads, which is an active blocker for reliable CI execution.

If a label is wrong, remove it manually and ping @patty-chow so the rules can be tuned. The bot will not re-label items that already have component labels.