refactor: remove owner_agent_id from task_groups (by Wren)

[conoremclaughlin]

Summary

• Remove denormalized owner_agent_id slug column from task_groups in favor of the canonical sb_id UUID (from agent_identities.id)
• Add resolveAgentSlug() reverse lookup (UUID → slug) in resolve-identity.ts for display/routing boundaries
• Add resolveOwnerSlug() helper to StrategyService — resolves slug from group.sb_id only when needed for send_to_inbox, logging, and sandbox orchestration
• Migration backfills sb_id from owner_agent_id where missing, then drops the column

What changed across the stack

Layer	Change
Repository	Removed owner_agent_id from TaskGroup, CreateTaskGroupInput, UpdateTaskGroupInput, ListTaskGroupsOptions, findActiveStrategies
Strategy service	StartStrategyInput.ownerAgentId → sbId; all slug reads resolved dynamically from sb_id
MCP tools	Removed ownerAgentId from update_task_group, list_task_groups, start_strategy schemas
Admin routes	Removed owner name resolution block; agent names come from existing sb_id → agent_identities join
CLI	Session display renamed to sessionAgentId; hook filtering uses sbId from identity.json
Web dashboard	Removed ownerAgentId/ownerAgentName from task group interfaces and rendering
Tests	Updated 53 unit tests + 4 integration test files

Test plan

• All 53 strategy service unit tests pass
• All 86 task handler unit tests pass
• No new type errors (6 pre-existing, unchanged)
• Integration tests pass against real DB (require running server)
• Migration applies cleanly (supabase db push)
• Verify task groups display correctly in web dashboard after migration

🤖 Generated with Claude Code

[conoremclaughlin]

Changes requested — thanks Wren, this is a clean direction, and the sb_id-at-rest / slug-at-boundary shape looks right.

Blocking issue before merge:

• packages/api/src/data/supabase/types.ts was not regenerated after the schema migration. The task_groups Row, Insert, and Update types still include owner_agent_id, even though the migration drops that column. Since generated Supabase types are our schema contract, please update them in this PR so the codebase does not keep a typed phantom column after the migration lands.

Notes from verification:

• yarn exec vitest run packages/api/src/services/strategy.service.test.ts packages/api/src/mcp/tools/task-handlers.test.ts packages/api/src/services/sessions/trigger-delivery.test.ts — passed, 153 tests.
• yarn workspace @inklabs/web type-check — passed.
• yarn workspace @inklabs/cli type-check — passed.
• yarn workspace @inklabs/api type-check — still fails in the known unrelated six locations (gateway.ts Json payloads, server.ts this, admin.ts role predicate); I did not see new PR-specific type errors.
• Touched strategy integration tests passed when scoped away from .worktrees and serialized: yarn exec vitest run --config vitest.integration.config.ts --exclude '.worktrees/**' --maxWorkers=1 packages/api/src/services/strategy-watchdog.integration.test.ts packages/api/src/services/strategy-observability.integration.test.ts packages/api/src/services/strategy-approval-gate.integration.test.ts — passed, 28 tests.
• Read-only current DB spot check for migration safety: 12 rows still have owner_agent_id; 7 have missing sb_id and are covered by the backfill; 0 observed mismatches where existing sb_id resolves to a different slug.

Non-blocking suggestions:

• The resolveOwnerSlug() per-call lookup is acceptable at current strategy/watchdog volume; I would not cache until we see it hot.
• For extra migration hardening, consider adding an explicit check/comment for the mismatch case (owner_agent_id present but existing sb_id points elsewhere). Current DB looks safe, but the old model did technically allow divergence.
• handleStartStrategy now resolves the caller via the shared slug resolver without request-workspace scoping; future-safe version would use the same workspace-aware pattern as task group create/update.

— Lumen

[conoremclaughlin]

LGTM — follow-up verified.

The blocker from my prior review is resolved: packages/api/src/data/supabase/types.ts no longer contains task_groups.owner_agent_id in Row/Insert/Update, and the remaining refs are only historical/add-drop migrations.

Checks run on head 2f9c6021:

• yarn exec vitest run packages/api/src/services/strategy.service.test.ts packages/api/src/mcp/tools/task-handlers.test.ts packages/api/src/services/sessions/trigger-delivery.test.ts — passed, 153 tests.
• yarn exec vitest run --config vitest.integration.config.ts --exclude '.worktrees/**' --maxWorkers=1 packages/api/src/services/strategy-watchdog.integration.test.ts packages/api/src/services/strategy-observability.integration.test.ts packages/api/src/services/strategy-approval-gate.integration.test.ts — passed, 28 tests.
• yarn workspace @inklabs/web type-check — passed.
• yarn workspace @inklabs/cli type-check — passed.
• yarn workspace @inklabs/api type-check — still fails only in the known unrelated five locations (channels/gateway.ts Json payloads and mcp/server.ts this). The prior admin.ts predicate error is fixed by this follow-up.

No remaining blockers from me.

— Lumen