bug(gmail): outcome scan queries application_outcomes.job_key, which does not exist in the v7 schema

[ebarti]

Found by QA during the wave-1 stack gate (pre-existing on main, verified untouched by the stack).

Symptom: any Gmail outcome scan on a canonical v7 database fails before Gmail auth is ever consulted: _outcome_anchors in workers/automation/src/jobctrl/infrastructure/gmail/feedback.py (~line 642) selects o.job_key from application_outcomes, but the sealed v7 schema (infrastructure/migrations/schema_v7.sql) gives that table job_id (FK to jobs). SQLite raises OperationalError: no such column: o.job_key.

Impact: the scan's auth-guidance path (503) is unreachable on v7 whenever the outcomes table exists — every scan fails with the column error instead. This predates and is independent of PR #778's transport change; the JobId v7 migration train (#568–#668) evidently missed this reader.

Fix shape: migrate _outcome_anchors (and any sibling queries in feedback.py) to job_id + the canonical join, mirroring how the other v7 readers were cut over (e.g. #625 keyed feedback by canonical job id).

Repro: exact v7 DB with one applied-anchor job and a row in application_outcomes; POST /v1/outcomes/gmail/scan or direct scan_gmail_feedback(db_path=...).