fix(core): block merging tasks in planning/specifying status

A task in column "in-review" but with status "planning" (or the legacy
"specifying" alias) was passing the merge eligibility check, so the
auto-merger would finalize a branch the user had just moved back to
re-plan. The hardcoded BLOCKING_TASK_STATUSES set didn't include either
status — only failed / awaiting-* / merging-* were checked.

Add both to the set so getTaskMergeBlocker reports them as blockers,
matching the expected user mental model of "moved to planning = won't
auto-merge".

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

packages/core/src/__tests__/task-merge.test.ts

@@ -46,6 +46,20 @@ describe("getTaskMergeBlocker", () => {
       .toContain("awaiting-inspection");
   });
 
+  it("returns reason when task has planning status", () => {
+    // Planning means the user moved the task back to triage/specification —
+    // its scope isn't finalized, so merging the in-flight branch is wrong.
+    expect(getTaskMergeBlocker({ ...baseTask, status: "planning" }))
+      .toContain("planning");
+  });
+
+  it("returns reason when task has the legacy 'specifying' status", () => {
+    // Legacy alias migrated to "planning" in db.ts; guard against any
+    // un-migrated rows that might still surface this value.
+    expect(getTaskMergeBlocker({ ...baseTask, status: "specifying" }))
+      .toContain("specifying");
+  });
+
   it("returns reason when task has incomplete steps", () => {
     expect(getTaskMergeBlocker({
       ...baseTask,

packages/core/src/task-merge.ts

@@ -6,6 +6,11 @@ const BLOCKING_TASK_STATUSES = new Set([
   "awaiting-user-review",
   "merging",
   "merging-pr",
+  // A task in planning/triage hasn't finalized its scope yet — letting it
+  // merge skips the work the user moved it back to plan. Same for the legacy
+  // "specifying" alias migrated to "planning" in db.ts.
+  "planning",
+  "specifying",
 ]);
 
 const NON_TERMINAL_STEP_STATUSES = new Set([