fix(linear): every imported issue was created into a column U11 deleted (#2860)

The **same** defect as the GitLab importer fixed in #2843, in a plugin
written from the same template — found only because I re-grepped my own
area with a wider pattern after declaring it clean.

```ts
export function buildLinearTaskCreateInput(issue: LinearIssue): TaskCreateInput {
  return { title, description, column: "triage", … };
}
```

`triage` was **deleted by U11**; the default board's lanes are `todo |
in-progress | in-review | done | archived`. An explicit `column`
**overrides** the intake column `createTask` resolves for the workflow
it selects — which is precisely how the literal survived the deletion.
Nothing rejects the write and nothing logs it: the route answers with a
task id, and the card is not on the board.

Fix: omit `column`, exactly as #2843 did for GitLab.

## Two tests were pinning the bug

```ts
expect(input.column).toBe("triage");                                        // import-linear.test.ts
expect(createTask).toHaveBeenCalledWith(objectContaining({ column: "triage" }));  // routes.test.ts
```

That is how this survived a lifecycle sweep that *did* reach the GitLab
importer. The census cannot see a lane literal passed as a **call
argument**, and the tests asserted the behaviour was intended — so both
the automated check and the human check said this file was fine.

Both now assert the column is **absent**, which is the property that
hands the decision to `createTask` and the one that fails on revert.

## The finding worth carrying forward

"We fixed the import path" was true of the forge everybody uses and
false of the other one. Two importers, one template, one of them
audited. When a defect is found in a file that had a sibling, the
sibling is the next place to look — and it is not something the census
will tell you, because this whole class is invisible to it.

## Revert proof (measured)

Restore `column: "triage"`:

```
AssertionError: expected 'triage' to be undefined
AssertionError: expected "vi.fn()" to be called with arguments: [ ObjectNotContaining{…} ]
```

## Verification

- `pnpm test:gate` — 161 / 487 / 13 / 71 passed
- `pnpm lint` — clean
- `tsc --noEmit` (`@fusion-plugin-examples/linear-import`) — clean
- full plugin suite — 35 passed across 5 files
- census `--strict` — exit 0 (unchanged: this class is invisible to it)

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

.changeset/linear-import-intake-lane.md

@@ -0,0 +1,7 @@
+---
+"@runfusion/fusion": patch
+---
+
+summary: Linear imports now land on the board instead of a lane that no longer exists.
+category: fix
+dev: `buildLinearTaskCreateInput` passed `column: "triage"`, a column U11 deleted, and an explicit column overrides `createTask`'s own intake resolution — so every imported issue was written into a lane no workflow declares. It now omits `column`. Same defect and same fix as the GitLab importer (#2843); the two tests that pinned `"triage"` now assert the column is absent.

plugins/fusion-plugin-linear-import/src/__tests__/import-linear.test.ts

@@ -50,7 +50,20 @@ describe("Linear import normalization", () => {
 
   it("builds triage task create input with durable metadata", () => {
     const input = buildLinearTaskCreateInput(issue);
-    expect(input.column).toBe("triage");
+    /*
+    FNXC:WorkflowLifecycleColumns 2026-07-30-16:35:
+    The import names NO column, so `createTask` resolves the workflow's intake lane.
+
+    This assertion used to demand `"triage"` — a column U11 DELETED — which is how the defect
+    survived: the test pinned the bug. An explicit `column` overrides `createTask`'s own intake
+    resolution, so every Linear import landed in a lane no workflow declares, with a 200 and a task
+    id and no card on the board.
+
+    Absence is asserted rather than a resolved id, because absence is precisely the property that
+    hands the decision to `createTask`. It is also what fails on revert.
+    */
+    expect(input.column).toBeUndefined();
+    expect(Object.keys(input)).not.toContain("column");
     expect(input.source?.sourceType).toBe("api");
     expect(input.source?.sourceMetadata).toEqual(expect.objectContaining({ provider: "linear", issueId: "lin-issue-1" }));
   });

plugins/fusion-plugin-linear-import/src/__tests__/routes.test.ts

@@ -63,7 +63,9 @@ describe("linear plugin routes", () => {
     const context = ctx();
     const result = await importSingleLinearIssue({ body: { issueId: "ENG-1" } }, context);
     expect(result).toMatchObject({ status: 201, body: { imported: true, duplicate: false, taskId: "FN-9" } });
-    expect((context.taskStore as any).createTask).toHaveBeenCalledWith(expect.objectContaining({ column: "triage" }));
+    /* FNXC:WorkflowLifecycleColumns 2026-07-30-16:35: the route must not name a column either —
+       `createTask` resolves the workflow's intake lane. Pinned `"triage"` before, a column U11 deleted. */
+    expect((context.taskStore as any).createTask).toHaveBeenCalledWith(expect.not.objectContaining({ column: expect.anything() }));
   });
 
   it("returns duplicate task id for existing imported issue", async () => {

plugins/fusion-plugin-linear-import/src/import-linear.ts

@@ -118,12 +118,25 @@ export async function findExistingLinearTask(taskStore: { listTasks?: (options?:
   return tasks.find((task) => taskMatchesLinearIssue(task, issue)) ?? null;
 }
 
+/*
+FNXC:WorkflowLifecycleColumns 2026-07-30-16:35:
+NO explicit `column`. An imported Linear issue enters INTAKE, and `createTask` resolves which column
+that is from the workflow it selects (`resolvedEntryColumn`); an explicit `column` OVERRIDES that
+resolution, which is exactly how this import kept naming `triage` after the column stopped existing.
+
+`triage` was DELETED by U11 — the default board's lanes are `todo | in-progress | in-review | done |
+archived` — so every Linear import wrote its card into a lane no workflow declares. Nothing rejects
+it and nothing logs it: the route reports success with a task id, and the card is not on the board.
+
+Identical shape and identical fix to the GitLab importer (#2843). Worth stating that this one is the
+reason to distrust "we fixed the import path": the two importers were written from the same template
+and only one of them was found by looking at the forge everybody uses.
+*/
 export function buildLinearTaskCreateInput(issue: LinearIssue): TaskCreateInput {
   const preview = buildLinearImportPreview(issue);
   return {
     title: preview.title,
     description: preview.description,
-    column: "triage",
     sourceIssue: preview.sourceIssue,
     source: {
       sourceType: "api",