Post-merge run strands its output on its own branch

[suleimansh]

What we found

The on-before-mergeable run (the follow-up fired after setReadyForMerge()) writes its output to a branch nobody merges:

* the-framework/surge-pricing-followup
  22be1cf  Record surge pricing decision and business knowledge   <- DECISIONS.md + KNOWLEDGE-BASE.md
  main: has neither file

So the #556 quality TODO entries and the #537 business-knowledge docs only exist on a stranded branch. The next run branches from main and cannot see them, which defeats #537: the knowledge docs only work if the next run can read them.

Why it happens

The follow-up is spawned as a plain framework prompt child (runOnBeforeMergeable -> spawnPromptRun). That child gets the full #326 system prompt, including the ### Session name step:

1. If the repository has uncommitted changes, create a commit
2. Create a <SESSION_NAME>
3. Create a new branch the-framework/<SESSION_NAME> and git checkout it
4. Call setSessionName(<SESSION_NAME>)

So before writing anything, the follow-up commits, branches, and checks out a new branch, then writes its output there. The step is correct for a session; the follow-up is not a session, it is a follow-up to one.

The fix

Skip the session-name step for this run so it stays on the session's current branch, where its output rides to review and merges with the work.

Two ways:

• MVP (implemented): spawn the follow-up --vanilla. That drops the whole built-in System prompt #326 prompt, and with it the ### Session name step, so no new branch. The follow-up prompt is self-contained (it names the TODO file and the knowledge docs itself), and the always-on emit protocols stay. One flag.
• Targeted (alternative): drop only the ## Before starting changes section, keeping the rest of the built-in prompt. More precise, a little more plumbing.

Scoped to the on-before-mergeable queueing run only. The maintainability/security preset runs are also follow-ups, but each is a separate focused refactor that arguably wants its own branch/PR, so they are left as they are.

One decision for review

Confirm the intended landing spot is the session's current branch (so the output merges with the work). Both #556 (TODO entries) and #537 (knowledge docs) read that way. The related setting idea (fire the follow-up eagerly on setReadyForMerge() vs only after the actual merge) is orthogonal: on the session branch, it lands correctly either way.