[iscekic]

Owner registration already resolves ~ aliases to their concrete catalog target (#7582), but owner rows registered earlier stay alias-keyed. The owner queue then measures an alias beside its concrete target, paying for the same inference twice, and alias results can never be reused.

Change

• Before the owner queue claims a batch, every pending owner-requested alias row whose target resolves in the catalog hands its owner request to the concrete pair (same variant; created pending when absent) and drops its own flag, in one D1 batch guarded on status = 'pending'.
• A variant the target no longer offers only loses the flag; the next status lookup re-admits the target's current pairs.
• Aliases whose target is missing from the catalog keep today's behaviour.
• Running, failed and ready alias rows are untouched, so nothing is double-claimed and historical results stay as they are.
• This doubles as the data cutover: existing pending alias rows convert once on the next owner drain. No schema change.

Tests

• Real-SQLite tests: pending alias converts exactly once, alias plus concrete leave one measurement, missing target keeps the alias, unsupported variant drops the flag, non-pending rows never move.
• drainQueue test: aliases are collapsed before the batch is claimed.
• On a VM: typecheck, oxlint, the service vitest suite and pnpm smoke:scheduler pass.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (6 files)

• services/auto-routing-benchmark/README.md
• services/auto-routing-benchmark/src/db.ts
• services/auto-routing-benchmark/src/owner-alias-sql.test.ts
• services/auto-routing-benchmark/src/platform-models.ts
• services/auto-routing-benchmark/src/profile-runs.test.ts
• services/auto-routing-benchmark/src/run.ts

---

_{Reviewed by deepseek-v4.1-flash · Input: 54.8K · Output: 30.6K · Cached: 1.6M}

_{Review guidance: REVIEW.md from base branch main}