GitCafe driver: follow-ups for versecafe #17744

@versecafe — follow-ups from an end-to-end run of the GitCafe driver (#17681) against git.cafe. None of these block merging; they need someone who knows GitCafe's intended behavior.

1. SSH clone URL. The driver advertises ssh@<host>:owner/name.git (carried over from feat(forges): GitCafe support #17324). GitCafe's API returns no clone URL and the cafe CLI only builds HTTPS URLs, so we could not confirm the SSH user. Is ssh@ correct, and is there an API field we should read instead? SSH has not been tested end to end.

2. capabilities.comment is false while commenting works. On a PR in a repo I own, GET /pulls/{n} reports comment: false, yet cafe pr comment and POST /pulls/{n}/comments/ succeed (token scopes include comment contents/moderation write). The driver uses that flag to hide T3's comment composer, so GitCafe PRs get no top-level comment box. Is the flag meant to mean something else, or is it a GitCafe bug?

3. Problem detail as user-facing text. The driver surfaces GitCafe's problem detail/title (collapsed to one line, capped at 300 chars) as the error message, because it is often the only actionable text. Our service conventions prefer normalized categories over host-supplied text. Is GitCafe's detail intended to be shown to end users?

4. No way to stack an existing PR. T3 opens PRs against the default branch, and cafe pr edit --base answers "Retargeting standalone pull requests is not implemented in GitCafe yet", while cafe stack link needs a linear chain of bases. So stacks can only come from cafe stack submit. Is retargeting planned, or should the driver create stacked PRs through the stacks API directly?

Also worth knowing: @gitcafe/cli is Bun-only (globalThis.Bun), so installs through Node-based global installers (e.g. vp i -g) crash on start.