[Improve] Detect GitLab, Gitea, and Azure DevOps MR URLs for task PR links

[roomote-roomote-v1]

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

What changed

Task PR/MR link detection now recognizes GitLab (/-/merge_requests/), Gitea (/pulls/), and Azure DevOps (/pullrequest/) URLs from tool results and free text, not just github.com/.../pull/N.

Detected links persist with the correct provider and host on task_pull_requests and cloud_jobs.prSourceControlProvider. Where possible, non-GitHub title/status metadata is fetched through the existing multi-provider read path; GitHub continues to use the installation-token path.

Additionally, Slack PR inactivity scheduling stays GitHub-scoped so multi-provider completion text cannot fall into the GitHub-only baseline fetch.

Why this change was made

GitLab/ADO/Gitea tasks that opened MRs via CLI, delivery tools, or pasted links never got a task↔PR association, because transcript parsing always assumed GitHub. That left multi-provider work with unlinked MRs even when the URL was clearly present.

Impact

Completing a task with a GitLab/Gitea/ADO MR URL (for example https://gitlab.com/acme/api/-/merge_requests/42) now associates that MR with the task the same way GitHub PRs already do, so task PR links and cloud-job PR provider metadata stay accurate across providers.

[roomote-roomote-v1]

1 issue outstanding. See task

• packages/sdk/src/pull-request-links.ts:477: Detect execute-tool outputs from non-GitHub PR/MR CLIs. The new URL parser can recognize GitLab/Gitea/ADO links, but execute tool results are still only dispatched through gh pr create, gh pr checkout, and gh pr list helpers, so a successful command like glab mr create --fill that prints https://gitlab.com/acme/api/-/merge_requests/42 returns no detected PRs and never reaches persistence.