chore(attribution): renumber migrations to 167-173 after syncing main

Merged latest main (which took 166_project_dates) and shifted the attribution
migration series off the 166 collision: 166->167 agent_task_attribution,
167->168 accountable_user, 168->169 rule_version, 169->170 rule_version_index,
170->171 fail_closed, 171->172 trigger_publisher, 172->173 invariant_check.
Updated the internal cross-references in the migration comments accordingly.
Fixes TestMigrationNumericPrefixesStayUniqueAfterLegacySet on the merge tree.

Co-authored-by: multica-agent <github@multica.ai>

server/migrations/168_agent_task_accountable_user.up.sql

@@ -1,7 +1,7 @@
 -- Human Attribution, Phase 1 — split the accountable human off originator_user_id
 -- (MUL-4302, decided by Bohan on the MUL-4302 thread).
 --
--- Migration 166 stamped provenance (originator_source, evidence, lineage) ONTO
+-- Migration 167 stamped provenance (originator_source, evidence, lineage) ONTO
 -- originator_user_id, treating that one column as both "who authorized this run"
 -- and "who is accountable for it". Those are two different questions with two
 -- different lifetimes, and collapsing them onto one column is a latent hazard:
@@ -39,7 +39,7 @@
 -- lock).
 --
 -- NULL does NOT mean "pre-migration row" here. Unlike originator_source (which
--- every new enqueue path now stamps non-NULL, migration 166), accountable_user_id
+-- every new enqueue path now stamps non-NULL, migration 167), accountable_user_id
 -- is legitimately NULL on NEW rows too, whenever the row's audit source resolved
 -- no human yet: run_only autopilot writes originator_source='unattributed' with a
 -- NULL accountable until rule_owner lands, and any classified-unattributed path is

server/migrations/173_agent_task_attribution_invariant_check.up.sql

@@ -18,11 +18,11 @@
 -- raised by Elon). `NOT VALID` skips the initial scan, but Postgres STILL checks a
 -- pre-existing row whenever a later UPDATE touches it — even an UPDATE that leaves the
 -- attribution columns alone. Cross-deployment stale queued/running tasks predate
--- `167_agent_task_accountable_user`, so they carry (originator_user_id set,
+-- `168_agent_task_accountable_user`, so they carry (originator_user_id set,
 -- accountable_user_id NULL); their next claim / complete / cancel by the new backend
 -- would fail a bare invariant CHECK.
 --
--- `originator_source` was added by `166` with no default/backfill, so a NULL there does
+-- `originator_source` was added by `167` with no default/backfill, so a NULL there does
 -- NOT strictly mean "row predates the migration" — it means the row was written by a
 -- writer that does not populate attribution: (a) rows created before this PR's
 -- migrations; (b) during a rolling deploy, NEW rows an older, not-yet-replaced backend