Consolidate per-VM flags into global flags in op-challenger

## Problem

`op-challenger` currently exposes many flags in two parallel forms: a global `--` and a per-game-type `---` (e.g. `--cannon-rollup-config`, `--cannon-kona-rollup-config`, `--super-cannon-rollup-config`, `--super-cannon-kona-rollup-config`). The mechanism is implemented in `op-challenger/flags/vm_flag.go` and applied to several flags in `op-challenger/flags/flags.go`, including:

- `--prestates-url`
- `--rollup-config`
- `--l2-genesis`
- `--l1-genesis`
- `--depset-config`

This is confusing for operators and is being used inconsistently. More importantly, several of these are not actually VM-specific concepts — they are **network-global**:

- The L1 genesis is a property of the L1 network.
- The L2 genesis, rollup config, and dependency set are properties of the L2 chain (and superchain), not of the proof VM.
- The same chain produces the same L2 genesis / rollup config / depset regardless of whether it is being disputed via Cannon, Cannon-Kona, Super-Cannon, or Super-Cannon-Kona.

Allowing these to be set per VM makes it possible (and easy) to configure them inconsistently across game types on the same chain, which is a footgun rather than a feature.

## Proposal

1. **Audit every flag that currently uses `VMFlag`** and classify it as either:
- **Network-global** — must be the same regardless of game type. Drop the per-VM forms; keep only the global flag. Examples: `--rollup-config`, `--l2-genesis`, `--l1-genesis`, `--depset-config`.
- **Genuinely VM-specific** — varies meaningfully between VMs. Keep VM-specific flags only. Examples: `--cannon-bin`, `--cannon-server`, `--cannon-prestate`, `--cannon-kona-server`, `--cannon-kona-prestate`, snapshot/info frequencies.
- **Ambiguous** — discuss case-by-case. `--prestates-url` is a candidate (prestates are commitment-keyed, so one URL should suffice; but operators may want per-VM mirrors).

2. **Goal:** every config value has exactly one canonical flag and one canonical env var, so it only needs to be specified once and is read from one location.

3. **Backwards compatibility:** keep the deprecated per-VM forms working as aliases of the new global flag, with a clear startup warning naming the replacement whenever a deprecated form is set. If both the global and a deprecated per-VM form are provided, the global takes precedence (and the deprecated one still warns). Schedule removal of the deprecated forms in a follow-up.

## Out of scope

- Renaming or restructuring flags that are not currently per-VM.
- Changing the underlying config plumbing beyond what's needed to remove the per-VM read paths.

## Acceptance criteria

- [ ] Each currently-VMFlag flag is classified as global, VM-specific, or removed.
- [ ] Network-global flags have only one canonical form; per-VM forms are deprecated aliases with a startup warning.
- [ ] When both forms are set, the global value wins and the deprecated form still warns.
- [ ] In-repo docs / READMEs / devstack / op-deployer references are updated.
- [ ] Deprecation removal scheduled for a follow-up issue.