Populate pr_url from a PR-based branch identity

[williamthorsen]

Problem

A PR-<n> branch identity (#950) names the branch and artifact directory, but the manifest's pr_url stays null, so the identity's PR number never becomes a usable URL. PR-consuming skills (review-pr, respond-to-review, merge-pr) can't resolve the PR from the identity that names it — the caller must supply it explicitly each session.

Context

#950 established PR-<n> as a recognized branch identity. The manifest already carries a pr_url field with --set-pr-url / --clear-pr-url mutation flags; pr-source-resolution.md governs how PR-consuming skills resolve and persist a PR URL, and pr-resolution.md documents the per-platform URL shapes. Those shapes take host and path from the platform (github.com/{owner}/{repo}/pull/{n}, bitbucket.org/{workspace}/{repo}/pull-requests/{n}, Cloud only), so only owner/repo comes from the git remote; the manifest's scm field selects the shape.

Proposed solution

When the branch-derived identifier is a PR-<n> sentinel, seed pr_url in the manifest by building the scm-selected URL shape from the remote's owner/repo and the PR number — mirroring how ticket_url is seeded from a base URL and a ticket id. An explicitly stored pr_url still overrides the seeded default. Builds on #950.

Acceptance criteria

Must have

• For a PR-<n> identity, the manifest's pr_url is populated with the scm-selected URL built from the remote's owner/repo and the PR number (null when the remote cannot be resolved).
• The URL shape respects the manifest's scm (GitHub …/pull/{n} vs Bitbucket …/pull-requests/{n}).
• Non-PR identities leave pr_url seeding unchanged (stays null).
• An explicitly stored pr_url overrides the seeded value.
• New and modified behavior is covered by tests.

Should have

• pr-source-resolution.md documents that pr_url is seeded from a PR-<n> identity, mirroring the ticket_url seeding note in ticket-source-resolution.md.