The terminal shows a repository's upstream, checks it now, and lets an admin turn following on or off #4361

The About card (I) in the terminal now shows a repository's upstream. An admin of the repository can check it now and turn following on or off. The new test and the existing About, archive and provenance tests pass, and the type check is clean. I did not run the whole check suite.

• Upstream row: upstreamRows in src/tui/screens/about.ts shows the address, branch, last check and standing, for example example.invalid/owner/armature main · checked 2m ago · up to date. When following is off it shows off.
• Who sees it: only an admin of the repository, the same rule as the web About line (followShown/canAdmin). Mirrors don't get the row or the keys.
• u check upstream now: it appears only while following is on. It calls checkUpstreamNow, the action the settings page uses, and toasts the answer (checkedWords or the refusal text).
• f follow or stop following: it calls setFollowUpstream with a blank address and branch. That keeps the saved ones, as the page does when turning off. With no saved address it toasts "set the upstream address in the web settings first". Pointing at a new upstream URL stays on the web settings page.
• Test: test/tui-upstream.test.ts shows a guest and a non-admin user seeing no row and getting nothing from f or u. The owner sees the row, presses u and gets the refusal text for an unreachable upstream, then turns following off and on with f.

Left out or different from the issue:

• Gating: the issue says writer-gated for the check key. The page's check, checkUpstreamNow, refuses anyone who isn't an admin, so I gated the check key on admin too rather than bypass it.
• Writer case: on a personal repository only the owner can write or admin, so the test can't tell a writer from an admin. I didn't set up an org just for that.
• Successful check: the test's check hits an unreachable address, so a successful check or a proposal isn't driven end to end here. The action itself has its own tests.

Closes #3559

The About card (I) in the terminal now shows a repository's upstream. An admin of the repository can check it now and turn following on or off. The new test and the existing About, archive and provenance tests pass, and the type check is clean. I did not run the whole check suite.

• Upstream row: upstreamRows in src/tui/screens/about.ts shows the address, branch, last check and standing, for example example.invalid/owner/armature main · checked 2m ago · up to date. When following is off it shows off.
• Who sees it: only an admin of the repository, the same rule as the web About line (followShown/canAdmin). Mirrors don't get the row or the keys.
• u check upstream now: it appears only while following is on. It calls checkUpstreamNow, the action the settings page uses, and toasts the answer (checkedWords or the refusal text).
• f follow or stop following: it calls setFollowUpstream with a blank address and branch. That keeps the saved ones, as the page does when turning off. With no saved address it toasts "set the upstream address in the web settings first". Pointing at a new upstream URL stays on the web settings page.
• Test: test/tui-upstream.test.ts shows a guest and a non-admin user seeing no row and getting nothing from f or u. The owner sees the row, presses u and gets the refusal text for an unreachable upstream, then turns following off and on with f.

Left out or different from the issue:

• Gating: the issue says writer-gated for the check key. The page's check, checkUpstreamNow, refuses anyone who isn't an admin, so I gated the check key on admin too rather than bypass it.
• Writer case: on a personal repository only the owner can write or admin, so the test can't tell a writer from an admin. I didn't set up an org just for that.
• Successful check: the test's check hits an unreachable address, so a successful check or a proposal isn't driven end to end here. The action itself has its own tests.

I added the README paragraph and pushed it to the same branch. I didn't run any tests, since only the README changed.

The paragraph is in ## Following an upstream, replacing the old line that said there was no button or page for it. It covers:

• upstream row: About (I) shows it to an admin of the repository and to nobody else. It gives the address, branch, last check and standing, and off when following is off.
• u: checks now while following is on, through the settings page's own action.
• f: turns following on or off through setFollowUpstream. It keeps the saved address and branch. When none is saved it refuses with "set the upstream address in the web settings first".

I did not do juniper's two smaller points:

• Successful check: a test would need a reachable upstream, which the sandbox doesn't have. checkUpstreamNow already has its own tests for the success path.
• Writer vs admin: a personal repository has no writer who isn't also its owner. Showing the difference would need an org and team fixture, which seemed out of proportion here. The terminal reuses the page's canAdmin gate, and test/tui-upstream.test.ts covers a guest and a non-owner getting no row and no keys.

I didn't check the preview.