fix(workspace): keep per_run workspaces run-scoped (BLO-19063)

[kkroo]

Thinking Path

• Paperclip runs AI agents through heartbeat, which selects or provisions an execution workspace before each run.
• Per-run worktree isolation derives a run-unique branch during realization.
• A persisted reuse_existing binding previously allowed later runs to bypass realization and return to the first run tree.
• The App-authored predecessor fix(workspace): never restore a per_run execution workspace (BLO-19063) #1154 fixes that path but cannot satisfy the independent protected-merge review gate.
• This kkroo-authored successor reapplies its final reviewed behavior on current master, including the actionable configuration-overlay feedback.
• The benefit is that an explicitly per-run workspace is never silently shared across runs.

Linked Issues or Issue Description

Refs BLO-19063. Supersedes the App-authored #1154; the original remains open and unchanged.

A GitHub duplicate search for per_run workspace found #1154 and its merged prerequisite #1143 as the only overlap. ROADMAP.md has no conflicting planned core work.

What Changed

• Refuse to restore an active reuse_existing workspace whenever the effective strategy resolves to runScope: "per_run".
• Do not persist a contradictory reuse_existing pin for a per-run workspace, including legacy pins created before the setting changed.
• Resolve the predicate across issue settings, project policy, agent configuration, and the applicable issue adapter-config overlay.
• Make model-profile configuration unable to alter workspace strategy, so the pre-realization predicate and realized host config cannot diverge.
• Cover policy precedence, stale pins, override upgrades/downgrades, shared-workspace behavior, and model-profile isolation.

Verification

cd server && pnpm exec vitest run --no-file-parallelism src/__tests__/heartbeat-workspace-session.test.ts src/__tests__/heartbeat-model-profile.test.ts
# 2 files, 226 passed

cd server && pnpm exec vitest run --no-file-parallelism src/__tests__/execution-workspace-per-run-isolation.test.ts src/__tests__/execution-workspace-policy.test.ts src/__tests__/issue-workspace-command-authz.test.ts
# 3 files, 29 passed

cd server && pnpm run typecheck
git diff --check

The focused suites emit an expected optional-local-adapter warning for an absent taalas-chatjimmy-wrapper; all assertions passed.

Risks

Low and intentional. per_issue and shared-workspace restore behavior remain unchanged. Explicit per_run now always realizes a fresh workspace, trading reuse for the isolation it advertises. Model profiles no longer control workspace placement. No schema, migration, or API change is included.

Model Used

OpenAI Codex, GPT-5. Tool-assisted GitHub review-context inspection, source reconstruction, isolated-worktree editing, and local test/typecheck execution; context window is platform-managed.

Checklist

• I have included a thinking path that traces from project context to this change
• I have specified the model used (with version and capability details)
• I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work
• I have searched GitHub for duplicate or related PRs and linked them above
• I have linked the existing issue and predecessor PR
• I have run tests locally and they pass
• I have added or updated tests where applicable
• If this change affects the UI, I have included before/after screenshots — n/a, server-side only
• I have updated relevant documentation to reflect the behavior — code and regression coverage document this internal path
• I have considered and documented any risks above
• All Paperclip CI gates are green — pending this push
• Greptile is 5/5 with no open P2s, recommendations, or follow-ups — pending review
• I will address all Greptile and reviewer comments before requesting merge

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[allyblockcast]

🔗 Paperclip issue: BLO-19063

[kkroo]

@ally Please review this exact independent-successor head: 5c41efd9a063012a2858e9ea6feef0dfedc74ff9.

This kkroo-authored successor preserves #1154's final reviewed per-run workspace isolation fix, including the configuration-overlay finding. The App-authored original #1154 remains open and unchanged.

Local evidence: 226 heartbeat/model-profile tests, 29 policy/isolation/authz tests, and server typecheck passed. Auto-merge is intentionally off pending current-head App and User attestations plus CI.

[allyblockcast]

Ally — Consolidated PR Review

Lenses: pr-review-toolkit (code, tests, comments, errors, types) + gstack/review + native-codex.
Reviewed head: 5c41efd

Critical Issues (0)

Important Issues (1)

• [gstack/review] server/src/services/heartbeat.ts:21100 — Per-run workspaces leak as active after every sequential run. With an issue already pointing at an active workspace, this new guard makes reusableExistingExecutionWorkspace null. The run then creates and points the issue at a new workspace, but the only old-workspace transition at server/src/services/heartbeat.ts:21759 is guarded by that same now-null variable. The old worktree remains active indefinitely, and its desired runtime services are restarted on process startup (workspace-runtime.ts:6116).
  • Track ownership by run and transition/clean up completed per-run workspaces without retiring one that a concurrent run still owns; add an integration test covering two sequential runs and the old workspace's terminal status.

Suggestions (0)

Strengths

• The policy and issue-level override resolution is deliberately centralized, preventing the reuse predicate from drifting from the realized configuration.
• The regression coverage exercises policy precedence and the previously missed adapter override path.

Recommended Action

1. Address the Important workspace lifecycle leak before merge.

[kkroo]

Closing as stale — this draft can no longer be landed as a diff.

Measured against master ac91e966:

• 822 commits behind
• 2 conflicting file(s) (git merge-tree --write-tree)

At that distance the surrounding code has moved out from under the patch, so "resolve the conflicts" would mean rewriting it against a codebase it was never written for — not merging it. Reopening is cheap if the branch is still wanted; the commits are untouched.

Closing the PR does not close the underlying issue. Where this PR referenced a BLO issue, that issue remains the record of intent and the place to re-implement from, against current master.

No judgement here on whether the original problem still exists — I did not verify that per-PR, and it should be re-checked before any re-implementation, since some of these may already have been fixed independently.