fix: dump progress output and stricter rate limit overrides

[joshiste]

Two follow-ups left open from the review of #35.

Progress during the list-gathering phase

experiment dump fetches every team's experiment list up front so it can report the size of the walk before starting it. Those requests are paced like any other, so on a tenant with many teams — or with a reduced STEADYBIT_RATE_LIMIT_* allowance — nothing was printed until all of them had arrived. While testing #35 that was over ten minutes of silence, which is indistinguishable from a hang.

A dot per team now lands as each list comes back:

Listing experiments for 3 teams...
Fetching experiments for team MCP (MCP)... experiments: 1, executions: 0
Fetching experiments for team Empty (EMP)... experiments: 0, executions: 0
Fetching experiments for team Webhook (WEBHOOK)... experiments: 1, executions: 3
Written 2 experiments with 3 executions

Stricter parsing of the rate limit overrides

The overrides went through Number, which reads 0x10 as 16, 1e3 as 1000 and 2.5 as two and a half. None of those is how a request count gets written on purpose, and accepting them changes how hard the CLI hits the platform without saying so — the same quiet failure the warning on a bad value exists to prevent.

Plain decimal digits are now required; surrounding whitespace is still tolerated.

0x10   -> Ignoring STEADYBIT_RATE_LIMIT_BURST: '0x10' is not a positive whole number. Using 100.
1e3    -> Ignoring STEADYBIT_RATE_LIMIT_BURST: '1e3' is not a positive whole number. Using 100.
2.5    -> Ignoring STEADYBIT_RATE_LIMIT_BURST: '2.5' is not a positive whole number. Using 100.
' 10 ' -> accepted

Verification

npm run ci green at both commits (82 and 88 tests), so the history bisects cleanly. Both changes were also exercised against a live develop tenant — the output in both sections above is real, not illustrative.