MJCLI: mj migrate default request timeout (300s) too low for baseline — document/raise/auto-bump

## Summary
`mj migrate`'s default request timeout (300s) is too low for the current baseline: at least one baseline batch exceeds it, and the failure is opaque.

## Repro
Running `mj migrate` on a fresh DB (v5.48 release prep) failed twice at the baseline until `MJ_MIGRATION_REQUEST_TIMEOUT=1800000` was exported. Failure modes seen:
- `Migration failed: … Timeout: Request failed to complete in 300000ms`
- the uglier cascade: `Failed at batch NNNN: Failed to cancel request in 5000ms` → `Requests can only be made in the LoggedIn state, not the Final state` — the driver's cancel-on-timeout couldn't be acked, the connection was torn down, and the DB was left **half-applied** (requires drop + recreate before retry).

(Root cause of the *server* slowness that session was Docker CPU contention, but even without that, the 300s default is marginal for the baseline.)

## Ask
One or more of:
1. Raise the default migration request timeout to something baseline-safe (e.g. 30 min), or
2. Auto-bump the timeout for baseline (`B*`) migrations specifically, or
3. At minimum, surface `MJ_MIGRATION_REQUEST_TIMEOUT` prominently in `mj migrate --help` and emit a clear "increase MJ_MIGRATION_REQUEST_TIMEOUT" hint when a batch times out.

The config knob already exists (`packages/MJCLI/src/config.ts`, `MJ_MIGRATION_REQUEST_TIMEOUT` → `dbRequestTimeout`); it's the default + discoverability that bite.

## Context
From the v5.48.0 release. Documented in DEPLOYMENT.md Step 3 via #3165; this issue tracks the CLI-side improvement.

Start with packages/MJCLI/src/config.ts, where MJ_MIGRATION_REQUEST_TIMEOUT maps to dbRequestTimeout, then run `mj migrate --help` and trace the timeout and batch-failure handling described in the issue. Agree on whether to raise, auto-bump, or document the default; done means the chosen behavior is discoverable and timed-out batches provide a clear recovery hint.

Written by the indexing model from the issue text.