design(synthetics): make the browser step cap a deployment setting

Problem

A browser journey cannot hold more than 50 steps. MAX_STEPS is a hard-coded const in src/config/src/meta/synthetics.rs, with no environment variable behind it, so no deployment can change it. A recorder session that produces 53 steps fails to save with Validation: config.steps: too many steps (53 > 50), and the only workaround is to split the journey by hand.

What competitors do

They bound a browser check by run time, not by step count.

• Datadog states no step limit for browser tests. The 10-step cap it publishes is for multistep API tests, and support raises it on request.
• Checkly counts no steps either. It stops a browser check at 240 seconds.

Proposal

Make the cap a deployment setting, and keep the caps that actually protect the system as they are.

ZO_SYNTHETICS_BROWSER_MAX_STEPS, default 50, reload class Hot. The validator reads it through get_config() at validation time, so /config/reload changes what the next save accepts with no restart. The name says BROWSER because the cap lives in validate_browser_config and applies to no other check type.

A value of 0, or one above 200, falls back to 50 and logs the reason. 200 is where the existing 256KB config payload cap binds, at roughly 1.2KB per step, so a larger value would only produce a second and more confusing error.

What does not change

The two caps that bound cost and correctness stay exactly as they are, and both still reject a journey the step cap would let through:

• MAX_STEPS_JSON_BYTES, 256KB of serialized steps.
• ZO_SYNTHETICS_MAX_CHECK_BUDGET_SECS, 840 seconds, which is the probe Lambda timeout.

Cloud keeps the default of 50. Only a self-hosted operator who sets the variable sees a different limit.