feat(cli): pipe deploy runner config flags to managed pool runnerConfig

[abcxff]

No description provided.

[abcxff]

Stack for rivet-dev/rivet

• #5413 feat(cli): pipe deploy runner config flags to managed pool r … 👈
• #5412 feat(dashboard): show connection token inline with get-or-cr …
• #5410 chore(dashboard): bump rivet-gg/cloud and adopt sdk connecti …
• #5411 feat(dashboard): add connection token issuing ui
• #5409 feat(dashboard): allow typing cpu value in compute tab
• #5408 feat(dashboard): add compute tab to namespace settings drawe …
• #5414 docs(compute): remove beta label from rivet compute
• #5407 fix(container-runner): report crashed child exits as errored …
• #5406 feat(rivetkit): report actor run() errors to the engine as e …
• main

Get stack: forklift get 5413
Push local edits: forklift submit
Merge when ready: forklift merge 5413

_{change qrmqkllz}

[claude]

Review

Small, focused change: pipes --drain-grace-period / --drain-on-version-upgrade through to the managed pool's runnerConfig, and moves max_concurrent_actors from an always-set top-level field into that same nested object. Code is clean and the new build_runner_config unit tests mirror the existing build_resources test style well.

Behavior change worth confirming (not a bug, just flagging)
runnerConfig is now only sent when at least one of --max-concurrent-actors / --drain-grace-period / --drain-on-version-upgrade is passed (build_runner_config returns None otherwise). Previously maxConcurrentActors was always included in pool_body, defaulting to 1000 client-side. This means a plain rivet deploy with no flags will now leave an existing pool's runner config untouched instead of resetting maxConcurrentActors to 1000 on every deploy. This looks intentional per the doc comment (it says this keeps the pool's current runner config), but since it changes default-path behavior for existing users, it would be good to confirm it's deliberate and maybe call it out in the PR description, which is currently empty.

Unrelated bound changes bundled into this PR
This diff also tightens/loosens two unrelated resource bounds that are not part of piping runner config flags:

• max_scale: 1..=500 to 1..=5000
• instance_request_concurrency: 1..=2000 to 1..=500

The instance_request_concurrency change in particular lowers the accepted max from 2000 to 500. Since client-side validation in build_resources now rejects values the CLI previously accepted, if the server-side computePoolConfigResources schema in the closed-source cloud-api has not actually changed to match, this would be a regression for anyone currently passing --instance-request-concurrency values between 501 and 2000. Worth double-checking these bounds against the current server schema before merging, since it is not verifiable from this repo and is not mentioned in the PR title or description.

Minor
--drain-on-version-upgrade uses the num_args = 0..=1, default_missing_value = "true" clap pattern, which correctly supports both bare --drain-on-version-upgrade and --drain-on-version-upgrade=false. Looks correct, just noting there's no test coverage for build_runner_config with only drain_on_version_upgrade set, a minor gap with low risk since it's a straight pass-through. Doc comments and help text ranges are consistent between deploy.rs and util.rs (5000/500/50000/3200 all line up).

Testing
Good unit test coverage for the new build_runner_config bounds (none-when-unset, partial fields, full object, both range checks). No integration test exercises Opts::execute's pool_body assembly directly, but that matches the existing pattern for this file (network-dependent, not unit-testable without a live cloud API), so not a gap introduced by this PR.

Overall: solid, well-tested change. The main thing I would want confirmed before merge is whether the max_scale / instance_request_concurrency bound changes are an intentional part of this PR or should be split out and verified against the server schema separately.