[kvlonge]

Why

A code location's warehouse metadata sync could loop forever on a warehouse where reading statistics takes longer than the 30-second page timeout. A timed-out statistics page halved the shared page limit and rewound to catalog. Once catalog finished, the limit reset to the maximum, so statistics retried at full size, timed out again, and kept the warehouse busy without ever completing a sync.

Changes

• Statistics pages have their own statistics_limit. It halves on a failed statistics read and survives the rewind through catalog. It returns to the maximum when a statistics scan completes, matching how limit recovers for the other kinds.
• When a page is too large to deliver, the limit for the current kind is halved.
• The regression test covers three cases: the retry after the rewind (it fails on the old code with 100 instead of 50), a catalog failure that leaves statistics alone, and recovery after a completed scan.

Remaining cost, not addressed here: a warehouse that needs a smaller page goes through the same timeouts again each cycle. Taking statistics reads off the warehouse is the next change.

DuckShop edge case: not applicable. This is location sync paging, not a project shape, data value or build lifecycle.

Verification

• cargo test -p sqlbuild-cli --lib location_metadata: passes.
• Live run on a Snowflake X-Small warehouse with 63 tables. Before the change, the sync never completed in 5½ minutes. With it, the first full sync completed in 3 min 31 s: two timed-out attempts (100, then 50), then success at 25.
• make check-ci: passes.

[kvlonge]

Folded into #1419 so the location sync fixes share one CI run. The branch is kept.