v0.25.0 — one harness, several pins, and long work goes to the worker that can hold it

You can now install a coder harness more than once, each copy pinned to a different model. The case that prompted it: OpenCode on Zen's free tier for everyday work, plus a second OpenCode pinned to a paid provider (e.g. Command Code's commandcode/deepseek/deepseek-v4.1-flash) for long-running and background tasks. The paid copy is spared both ACP transport timeouts and free-tier rate limits.

In og setup, repeat a harness's number in the coder picker. 2,2,4,1 installs two copies of coder #2, in that preference order, and the model step asks for a pin for each one. Choosing the same model twice for one harness gets a warning. Existing installs load and behave exactly as before.

Each copy is its own worker:

• The first keeps today's names (coder_zen, opencode). Later copies take their name from the pin's provider (coder_zen_cmdcode, opencode@cmdcode), or get a numeric suffix (coder_zen_2).
• og stats, dry marks (--mark / --clear), the start-time probe and the quota checks are tracked per copy. A rate-limit mark on the free copy never blocks the paid one.
• The liveness probe follows each copy's own pin against the unchanged free_models allow-list, so it still never bills.
• Cross-vendor review takes each copy's vendor from its pinned model, not from the harness.

The orchestrator now knows which workers can carry long jobs. Every roster line includes a generated long-running trait:

• yes for a native harness on a paid pin.
• no (ACP; long steps time out) for ACP workers.
• no (free-tier; rate-limited) for free-tier pins.

Test suites, migrations and big refactors go to a long-running: yes worker even over preference, and are split when no such worker exists. Dispatches now tell workers to run long commands in the background and poll them in short steps, never blocking on one long foreground command.