[Feat] Add Linear issues to Brain recall

[roomote-roomote]

​Opened on behalf of @mrubens. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

What changed

• Add a registered Linear Brain source that writes stable issue pages with workflow metadata, descriptions, and up to 20 recent comments.
• Reuse the deployment Linear OAuth connection and client with bounded GraphQL pagination, frozen incremental windows, durable cursors, and a daily visibility census.
• Retire deleted or inaccessible issue pages only after a complete creation-ordered census, while preserving archived issues as historical context.
• Expose Linear in Brain source status and namespace registries, document the behavior, and cover client normalization, progress, availability, census races, and retirement.

Why this change was made

Linear holds durable product context that was unavailable to Brain recall. The collector follows the decomposed per-source architecture without adding another credential or client path, and separates update-time freshness from stable full-workspace visibility checks.

Impact

Deployments with both Brain and Linear connected can recall visible Linear issues automatically. API work is bounded per collector pass, checkpoints advance only after page writes, and deleted or newly invisible issues converge safely without treating partial API responses as deletions.

Verification evidence: focused collector, Linear client, source availability, registry, settings-summary, and engine tests passed; public docs validation and broken-link checks passed; full repository lint, all-package typechecking, and pre-push oxlint, residual lint, fast typechecking, and knip checks passed.

[roomote-community]

No new code issues found. See task

• packages/sdk/src/server/lib/brain-linear.ts:397 — The census does not refresh inventory lastSeenAt, so the next sweep retires still-visible issues. — dismissed: this path uses upsertBrainCollectorItems, whose conflict update refreshes lastSeenAt; the focused database regression passes.

_{Reviewed 8366133}

[roomote-community]

persistCollectorItemUpdates ultimately calls upsertBrainCollectorItems, which uses onConflictDoNothing for an existing (collectorId, itemId). That means this census never refreshes lastSeenAt for issues already inventoried. On the next daily census, every still-visible issue has a timestamp older than sweepStartedAt, so the retire phase treats all of them as stale and deletes their Brain pages. The inventory write needs to update lastSeenAt (or use a collector-specific refresh path) for items observed during the sweep.

[roomote-roomote]

This finding conflates two different persistence helpers. The census returns itemUpdates, the BullMQ engine passes them to upsertBrainCollectorItems, and that helper uses onConflictDoUpdate to set last_seen_at = excluded.last_seen_at. Only seedBrainCollectorItems, which this path does not call, uses onConflictDoNothing. The focused database regression finds only items missing from a completed sweep passes and proves a re-observed inventory row is not returned by listBrainCollectorItemsBefore. No code change is needed.

[roomote-roomote]

Resolved the failed review as a false positive. The census already refreshes existing inventory through upsertBrainCollectorItems and its onConflictDoUpdate path; the separate seedBrainCollectorItems helper is the one that intentionally does not overwrite rows. The focused database regression passed, the review thread has the correction, and the review summary now records the finding as dismissed. No repository change was required; the reviewed head remains 3693baf. See investigation.