chore(migrations): renumber to 249/250 after main's duplicate-242 fix

#6239 resolved main's own duplicate 242 by shifting
242_workspace_teardown_dirty_trigger_guard to 243, which cascaded every later
prefix up by one. main now reaches 248 (248_agent_task_trigger_comment_index),
so this branch's 248 collided again. Ours move to 249/250; 250's header
reference updated to match.

The previous backend CI failure was that inherited duplicate 242 on main, not
this branch — it is fixed upstream now.

Verified: migration lint (all three prefix tests) passes on the merged tree;
fresh DB migrate up through 250; go test ./cmd/server ./internal/handler
./internal/attribution ./internal/service ./internal/migrations; pnpm typecheck 6/6.

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

server/migrations/250_issue_subscriber_opt_out_scope.up.sql

@@ -1,6 +1,6 @@
 -- MUL-5483 review follow-up: an opt-out has to remember HOW FAR it reaches.
 --
--- 248 gave every unsubscribe a tombstone, and HasAncestorOptOut treats any
+-- 249 gave every unsubscribe a tombstone, and HasAncestorOptOut treats any
 -- ancestor tombstone as "do not re-subscribe below here". That made the two UI
 -- choices — "unsubscribe from this issue" and "…and its sub-issues" — differ
 -- only for descendants that already exist: both silently suppressed FUTURE
@@ -11,7 +11,7 @@
 ALTER TABLE issue_subscriber ADD COLUMN opt_out_scope TEXT
     CHECK (opt_out_scope IN ('issue', 'subtree'));
 
--- Rows tombstoned by 248 predate the distinction. They were all written by a
+-- Rows tombstoned by 249 predate the distinction. They were all written by a
 -- path that suppressed future children, so 'subtree' preserves their observed
 -- behavior rather than silently widening or narrowing it.
 UPDATE issue_subscriber SET opt_out_scope = 'subtree' WHERE unsubscribed_at IS NOT NULL;