fix(ui): host-owned token links, an Unverified notice, and a labels capability

[Tryanks]

Summary

core::settings
  HostStatus  + token_url, access_token_url, token_scopes   (filled by each host adapter)
  HostProblem + Unverified                                   (a saved token not yet seen to work)
protocol
  PullRequestCapabilities + labels                           (wire note above PROTOCOL_VERSION)
services
  github    token_url https://{host}/settings/tokens/new?scopes=repo,read:org…   scopes repo, read:org
  forgejo   token_url https://{host}/user/settings/applications                   scopes write:repository, write:issue, read:user
  gitlab    token_url https://{host}/-/user_settings/personal_access_tokens?…     scopes api
            Saved PAT → Unverified until a request sent with it answers 2xx
  azure     token_url https://dev.azure.com/{org}/_usersSettings/tokens           scopes Code (Read & write), Pull Request Threads (Read & manage)
            Saved PAT → Unverified until a request sent with it answers 2xx
  bitbucket token_url id.atlassian.com API tokens, access_token_url the access-token docs
            SavedBearer → Unverified until a request sent with it answers 2xx
  worked    per host: the fingerprint of the last saved token (Saved / SavedBearer) that
            answered 2xx, one entry per host, cleared by forget_credential; Unverified only
            for an enabled host
  capabilities.labels: GitHub, Forgejo/Gitea, GitLab, Azure true; Bitbucket false
  forge::offered: SetLabels → Unsupported when labels is absent
ui
  source_control_settings  token kinds: scope hint + "Create a token" from status;
                           Bitbucket links from status (hardcoded Atlassian URLs removed);
                           Unverified = info notice (no warning glyph); [Set][Clear] everywhere;
                           Bitbucket no-credential notice no longer repeats "Not connected";
                           email field aria label "Atlassian account email for %{host}"
  pull_requests/meta       Labels row where capabilities.labels or the PR reports labels;
                           its Edit picker only where capabilities.labels (and permission)

Why HostStatus, not HostTerms: the token page depends on the host's authority (GitHub Enterprise, self-managed GitLab, a Forgejo mount path, the Azure organization), which only the adapter that resolves the host's credential knows; HostTerms is static per kind. The scopes travel with the URL so the row reads one owner.

Evidence

• Before: Source Control linked Atlassian URLs hardcoded in the panel, token kinds had no create-token link, no host reported an unverified token, Bitbucket's buttons were [Clear][Set], its no-credential notice repeated "Not connected", and a Bitbucket PR showed an empty "Labels · No labels" row.
  After:

Desktop: Source Control	Phone: Source Control

Desktop: Bitbucket PR meta (no Labels row)	Phone: Bitbucket PR meta (no Labels row)

Fresh TCODE_DATA_DIR, throwaway HOME, env -i with PATH=/usr/bin:/bin and HOSTNAME="Demo Mac", English, light. Synthetic project sample-app (remote git@bitbucket.org:atlassian/atlassian-connect-express.git); its one thread failed to start (no provider on PATH) and links public PR atlassian/atlassian-connect-express#547, read anonymously, so the PR shots show that public PR's content, not the maintainer's. The Source Control shots have bitbucket.org added with a fake access token (demo-access-token-not-real, never sent: the PR shots were taken before it was saved, and it was cleared again before the phone PR shot). The track is switched to "API token" so the "Create an API token" link and the Unverified notice show together. The Source Control shots were retaken after the rewording, on a fresh profile with bitbucket.org configured and the same fake token, and no PR. Dark theme was looked at on the phone, not attached.

Tests (new or changed):

• services::forge::tests::a_bitbucket_reopen_or_label_edit_is_refused (was a_declined_bitbucket_pull_request_is_not_reopened, extended): Bitbucket's capabilities lack labels, and SetLabels through the dispatcher answers Unsupported. Bitbucket's own act also refuses SetLabels, so this pins the user contract rather than isolating the gate; no other host lacks labels.
• source_control_settings::tests::an_unverified_token_gets_its_notice (new): through SourceControlPanel with a settings snapshot, a Bitbucket row with Unverified gets its notice and a connected GitLab row gets none. Fails when the panel skips the Unverified notice (checked by a local edit).
• pull_requests::detail::tests::the_labels_row_is_absent_where_the_host_has_no_labels (new): through PullRequestView and a conversation read, with the Reviewers row present in every case:
  • capability present, no labels: Labels row shown;
  • capability absent, no labels: row absent;
  • capability absent, a label reported: row shown.
    Each of the last two fails without its rule (checked by local edits). The test view has no session status, so it is read-only and never shows Edit; the "Edit only with the capability" half is not separately asserted.
• services::gitlab::tests::a_saved_token_is_unverified_until_it_is_used (new, no HTTP): a token saved in a temp store gives credential_status()["gitlab.com"].problem == Some(Unverified); with only GITLAB_TOKEN it is None. The existing answer_other conversation moved into a conversation() helper the new test reuses.
• No test deleted.

Checks on the final commit:

• cargo fmt --all --check: clean
• cargo clippy --workspace --all-targets --locked -- -D warnings: clean
• cargo nextest run --workspace --locked: 1158 tests run: 1158 passed, 13 skipped
• cargo machete: no unused dependencies
• Mobile and Web: left to CI.

Limitations:

• What a token has been seen to do is kept per host process. After every restart of the host, a saved GitLab or Azure PAT or a Bitbucket access token shows the notice again, until a pull request is read with it and Source Control is opened again. The wording ("Tcode hasn't used this token yet. It checks it on the first pull request it reads on %{host}.") claims nothing about a fresh save.
• The switch from Unverified to verified after a real read is not checked live; it needs a real token on each host. Status is recomputed when Source Control opens or a token is saved.
• N1, not addressed: GitLab's token link uses /-/user_settings/personal_access_tokens. Older self-managed GitLab servers (before 16.x) keep the page at /-/profile/personal_access_tokens, so the link may not land on that page for them.

Merge Danger

Door: two-way
Blast Radius: settings
Wire shape changes (HostStatus gains three fields, HostProblem gains unverified, capabilities gain labels) under the same PROTOCOL_VERSION, noted above it; client and host come from one tree. changed_files (#698) lines are untouched.

Closes #699