Wire up per-repo worker_model from registry when spawning workers

Summary

The RegistryRepo struct already has a worker_model: Option<String> field (store.rs:27) and the API endpoint /api/registry/overrides allows setting it per repo. However, when spawning a worker, Worker::new() always resolves the model via routing.resolve(ProcessType::Worker, None) — the per-repo override is never applied.

Problem

All workers use the same global model (e.g. claude-haiku-4-5), even when a specific repo would benefit from a stronger model for complex fixes. The infrastructure for per-repo overrides exists but isn't wired up.

Proposed Change

1. In spawn_worker.rs: Pass the repo context (from worktree or project) when creating the worker
2. In worker.rs: When resolving the model, check if the associated repo has a worker_model override in the registry — if so, use it instead of the global default
3. Optionally: Add a model or task_type field to SpawnWorkerArgs so the channel can explicitly request a stronger model for fix/review tasks

Affected Files

• src/tools/spawn_worker.rs — SpawnWorkerArgs struct, worker creation
• src/agent/worker.rs — model resolution in Worker::new()
• src/llm/routing.rs — RoutingConfig::resolve() already supports task_type
• src/registry/store.rs — worker_model field already exists

Context

Workers frequently fail CI checks, and the fix-worker (also Haiku) often can't resolve the issues. Being able to set worker_model = "anthropic/claude-sonnet-4-6" per repo would allow stronger models for complex projects while keeping Haiku for simple ones.

Start with SpawnWorkerArgs and worker creation in src/tools/spawn_worker.rs, then trace model resolution in src/agent/worker.rs and RoutingConfig::resolve() in src/llm/routing.rs. Use the existing worker_model field in src/registry/store.rs as the registry source. Done means a repo override is used when present and the global worker model remains the fallback.