Fixed

• Bitbucket pull requests with more than 100 changed files now list files
  past the first 100 (up to 500, and the view says when more remain).
• Keyboard focus survives inline confirmations in repository settings: opening
  one lands on Cancel, and cancelling it returns focus to the control you came
  from.
• The conflict banner shown during a merge, rebase, cherry-pick, or revert
  stays readable in a narrow sidebar: the status text shortens to fit, with
  the full text on hover.
• Repository settings and security-findings actions stay available through a
  brief connection drop, and the sign-in check and GitHub Pages settings say
  when GitHub couldn't be reached.
• Pull-request views keep what they could load and say so: comments, commits,
  checks, and review verdicts that couldn't be fully read are marked as
  partial, and pipeline logs say when only the newest jobs were checked.
• GitLab errors show the real reason, and connection problems say so plainly.
• Merge requests from GitLab forks list their pipeline checks, with each check
  linking to its job on GitLab.
• GitLab members: the owner of a personal project is marked "Owner", and its
  Remove button explains that the owner can't be removed. The Add button and
  each member's role picker also say why they're unavailable while disabled,
  and loaded members stay listed when a refresh fails (with a Retry) or waits
  for a connection.
• GitLab and Bitbucket run details report fetch failures. Failed-job logs keep
  available output, label unavailable logs, show an error if every fetch fails,
  and count failed jobs or steps omitted at the output limit.
• Held switches in repository settings now tell keyboard and screen-reader
  users why they can't be changed (offline, saving, inherited, or waiting on
  another setting), stay reachable by Tab, and per-row switches and role
  pickers announce which row they belong to.
• Error messages that mention a hostname like gitlab-429.example.com now get
  the clear couldn't-reach message when the network is the problem.
• Projects boards, My work, Actions, Run workflow, fork comparisons, project
  fields and Jira issues now say when they're waiting for a connection and
  keep what they already loaded, offering Retry only for a refresh that
  actually failed. Reconnecting refreshes them quietly, and Jira's status,
  priority and label menus keep their options through a failed refresh.
• Controls explain why they're waiting: Refresh runs says it's already
  loading, and a project board's Group by, date and saved-view choices plus
  the reviewer, assignee, milestone, label and Jira issue-type pickers say
  when they're waiting for a connection or couldn't load, calling a list
  empty only once it has loaded.
• Account status distinguishes account names and hostnames from connection
  outages.
• Sign-in and outage states read correctly on self-hosted GitLab and GitHub
  Enterprise hosts, when a GitLab host name, port, or project URL contains 429,
  and when a Bitbucket or Jira response stalls or drops partway through.
• A pull request check's log tail stays readable through a failed refresh,
  with a short note and a Retry, and Discussions keep what's on screen while
  a reconnect refreshes them. Pressing Retry in Discussions, the pull request
  and issue lists, Actions, and the Run workflow and Create Jira issue
  dialogs keeps keyboard focus in place.
• A pull request check's log offers a Retry, with the reason it couldn't
  load, even before any text has arrived. The Actions run list now says
  when a refresh failed or you're offline, with a Retry for a failed
  refresh. The Jira assignee search says when it's waiting for a
  connection, and a stack's Dissolve action explains when you need write
  access to use it.
• Pull-request file and review-discussion lists that couldn't be fully loaded
  are now marked as partial, with a retry where one helps, and AI reviews note
  a partial commit list in their prompt.
• GitLab pipeline views now list jobs beyond the first hundred: the merge
  request checks rollup, the run details view, and failed-job logs.
• GitLab merge requests and Bitbucket pull requests now say when their CI checks
  couldn't be loaded and offer Retry (or say they will load once you're back
  online).
• GitLab merge requests and Bitbucket pull requests say when their
  conversation couldn't be loaded and offer Retry (or say it will load once
  you're back online).
• Blame, file previews, and AI reviews on pull requests with very long commit
  histories now anchor to the pull request's true head commit, so reviews read
  the latest code and a head that was already covered is never re-reviewed.
• Pressing Retry on a project board that couldn't load, or in the board's
  Edit fields dialog, keeps keyboard focus in place, and that dialog says
  when its fields are waiting for a connection.
• Opening a ruleset for editing while offline says so and loads once you're
  back; an already-open ruleset keeps the loaded version and your draft under
  a notice when a refresh fails.
• Deleting a row in repository settings now moves keyboard focus to a
  neighboring row's control, or to the section's add field or button once
  the list is empty, and a confirm button keeps focus while its action
  applies, including when it fails.
• In-progress edits in Repository settings (General, Security, Pages, and
  Sponsor) survive background refreshes and connection blips: a failed refresh
  keeps the form and your draft on screen with a note and a Retry, and a first
  load that fails can be retried in place.
• Repository settings lists keep their loaded rows on screen when a refresh
  fails (with a short note and a Retry) or waits for a connection: webhooks,
  collaborators, rulesets, secrets and variables, and the GitLab and
  Bitbucket list sections. A list opened offline says it will load once you're
  back online, and a failed load names the permission it may need.
• While you're offline, Repository settings tells you what's waiting: the
  General, Security, and Pages forms say they'll load once you're back online,
  and actions that need a connection (adding webhooks, variables, secrets,
  members, and rules) say why they're unavailable and come back on their own
  when you reconnect. The Repository settings menu item also shows while your
  access is being checked.
• Repository settings actions that write to GitHub, GitLab, or Bitbucket say
  when you're offline: saves, deletes, role changes, toggles, webhook tests
  and redeliveries, and danger-zone actions all explain themselves and come
  back the moment the connection does.
• Sign-in and outage states stay accurate for hosts whose names carry digits
  or network words, like gitlab-429 or proxy.example.com.
• A stacked pull request's Stack section now tells a failed member lookup apart
  from a stack with nothing else in it: a lookup that failed says so and offers
  Retry (or says it will load once you're back online).
• A pull request's timeline events and a workflow run's logs stay on screen
  when a refresh fails or you're offline, with a short note and a Retry when
  the refresh failed. Timeline events or logs that haven't loaded yet say
  they're waiting for a connection.