feat: record linear_workspace_id on project-mapping rows (enable workspace-scoped mapping cleanup) — follow-up to #306

[scottschreckengaust]

Parent context: surfaced during PR #681 review by @isadeks (issue #306). Needs maintainer approved before implementation (ADR-003).

Finding

LinearProjectMappingTable rows carry no workspace identifier. The only writer — onboard-project (cli/src/commands/linear.ts:~1484) — writes linear_project_id, repo, label_filter, optional team_id, status, onboarded_at, updated_at. So any attempt to delete a workspace's project mappings (e.g. during bgagent linear remove-workspace) cannot attribute rows to a workspace and matches nothing.

Because of this, PR #681 (remove-workspace) removed its mapping-cleanup path entirely (it was a provable no-op reported to the operator as success). This issue restores that capability the correct way.

Scope

1. Record linear_workspace_id on LinearProjectMappingTable rows at onboard time (onboard-project writer).
2. Backfill or migration strategy for existing rows (they predate the field).
3. Once the field exists, re-add workspace-scoped mapping cleanup to remove-workspace (the DELETE handler cdk/src/handlers/linear-remove-workspace.ts): re-introduce the paginated mapping scan/delete filtered on linear_workspace_id, its projectMappingTable.grantReadWriteData grant, the --keep-mappings flag, and the longer Lambda timeout — all of which feat(cli): bgagent linear remove-workspace + DELETE route + fail-closed resolver (#306) #681 removed as dead code.
4. Consider a GSI on workspace_slug (registry) / linear_workspace_id (mappings) to turn the recurring slug→row lookups into Query (also noted in feat(cli): bgagent linear remove-workspace + DELETE route + fail-closed resolver (#306) #681 review N4).

Fulfills

The LinearProjectMappingTable deletion acceptance criterion of #306 that PR #681 deferred.

Refs #306