[Fix] PR footers hardcode @roomote instead of the configured GitHub app slug

[roomote-roomote]

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

What changed

PR provenance footers like “Follow up by mentioning @…” now use the deployment-configured GitHub App slug at write time when that slug is actually configured — not the schema default roomote.

Added normalizePrBodyAttributionAppMention for the leading Roomote attribution blockquote, and resolveConfiguredGitHubAppSlugIfConfigured so normalization only runs with a real configured slug (process env or deployment env table). If resolution finds nothing or fails cold, the agent-supplied body is left alone so a correct custom handle cannot be downgraded.

Why this change was made

Roomote injects the exact provenance line into the agent prompt via getPrBodyAttributionLine and asks the agent to prepend it verbatim. When prompt-time slug resolution falls through to the default roomote, footers on PRs such as #72 said @roomote even though this deployment’s slug is roomote-roomote. The write path now repairs that, without reintroducing the review risk of rewriting a correct mention back to the default.

Impact

New and refreshed pull request footers point at the correct GitHub App mention when the deployment has a configured slug. Unrelated body text is unchanged; only the leading provenance line’s mention / mentioning handle is rewritten, and only when a configured slug is known.

[roomote-roomote]

No new code issues found. Latest commit resolves the earlier downgrade edge case. See task

• packages/sdk/src/server/lib/pull-requests/source-control-pull-requests.ts:261 — Fixed: the attribution rewrite now runs only when a slug is actually configured. resolveConfiguredGitHubAppSlugIfConfigured() returns null when nothing is configured or resolution fails cold, and the caller skips normalization in that case, so a correct custom handle like @roomote-roomote is no longer downgraded to @roomote.

Review notes

Sync review of 5e0de88 against b858492. The new commit addresses the prior low-severity edge case cleanly:

• New resolveConfiguredGitHubAppSlugIfConfigured() returns string | null and never substitutes the schema default 'roomote', so a missing/failed slug resolution yields null instead of a fake default.
• createOrUpdateSourceControlPullRequestForTaskRun now only rewrites the attribution mention when that helper returns a real configured slug; otherwise the agent-supplied body is passed through untouched, preserving a correct custom handle.
• resolveDeploymentEnvVar already checks process env first and trims, so the helper's success path and its cold-failure process.env fallback stay consistent; the stale-cache fallback in the catch path mirrors the existing resolveConfiguredGitHubAppSlug behavior.

Targeted tests pass: @roomote/github resolve-app-slug 9/9 (including the new "returns null when nothing configured" and "returns null on cold resolution failure" cases) and @roomote/sdk pull-requests 21/21 (including the new "does not downgrade a correct custom-slug attribution when no slug is configured" case). No net-new issues.