Prepare 3.4.10: version, release notes, and the sign-in docs

[guys-inc-ops]

Everything that has to be true before release-3.4.10-linux1 can be tagged. Two of these are hard blockers — the release job fails, or publishes something wrong, without them.

1. The version — blocker

The .deb version comes from app/package.json, so a release built from 3.4.9 declares 3.4.9 again. apt only upgrades on a higher version, so no existing user would ever receive it. And since the pool rebuild landed in #36, reprepro now skips the incoming package outright and the repository keeps serving the old binary — the one with the OAuth secret in it.

3.4.10, not 3.4.9-linux2. The latter looks like the natural fork revision and is greater to dpkg, but it is a semver prerelease, so it sorts below 3.4.9 for any comparison the application itself makes:

dpkg:   3.4.9-linux2 vs 3.4.9 -> GREATER
semver: 3.4.9-linux2 gt 3.4.9 -> false   | prerelease: [ 'linux2' ]
semver: 3.4.10       gt 3.4.9 -> true    | prerelease: null

3.4.10 is correct in both orderings, and 3.4.10-linux1 satisfies isInitialTag() so the notes script works with no code change to that path.

2. The release notes — blocker

generate-release-notes.ts requires a changelog.json entry for the upstream version behind an initial tag and calls process.exit(1) without one. 3.4.10 was absent, so the release job would have failed before publishing anything.

Adding the entry exposed a second problem. Every fork-authored entry was silently dropped:

release entry does not match any format: '[Improved] Upgrade Electron to v39.8.10, from v32.1.2, …'

The entry regex requires a - #1234 tail naming an upstream issue, and formatReleaseNote hardcodes desktop/desktop/issues/{id} — so a fork PR number in that position would render as a link to an unrelated upstream issue. Entries may now omit the tail, and no dangling - is emitted when there are no ids.

Rendered locally both ways before committing. 3.4.10 produces the notes below; 3.4.9-linux1 still produces 0 unparsed entries, 10 upstream issue links, and the contributor credit intact, so the upstream path is unregressed.

Rendered 3.4.10 notes

## Added
- Sign in to GitHub.com using the OAuth device flow: Desktop shows a one-time code to enter in your browser, instead of handing off through a redirect

## Fixed
- The published packages no longer contain an OAuth client secret. Desktop authenticates as a public client, so no secret is built into the application

## Improved
- Upgrade Electron to v39.8.10, from v32.1.2, picking up seven major versions of Chromium security fixes
- Upgrade DOMPurify to v3, which sanitises rendered Markdown in the application
- Pin patched versions of tar-fs, cross-spawn, ansi-regex and @babel/runtime in the packaged application
- Release binaries now carry a build provenance attestation, so a download can be traced to the workflow run that produced it
- The APT repository is signed with a rotated key, and published under a per-project prefix at apt.guysinc.pub/github-desktop

## Removed
- Signing out no longer revokes the token on github.com. Revoking a server-side token required a client secret, which is no longer shipped; sign out now discards the token locally. Revoke access at github.com/settings/applications

3. Documenting the sign-in change

The device flow is the most visible change in this release and nothing documented it. A user who sees a one-time code where a sign-in page used to be has no way to tell whether it is working as intended. New section in docs/known-issues.md says it is expected from 3.4.10, and why: a desktop application cannot keep a secret, and earlier builds shipped one.

4. Signing out no longer revokes

It discards the token locally; the authorization stays listed on github.com until removed there. That is security-relevant, and someone handing over a machine needs to find it. Documented with the actual remedy (github.com/settings/applications) rather than left as a surprise.

Also corrected while in there: the organization-access entry described this as an OAuth App and linked the OAuth App approval flow. It is a GitHub App (Ov23li… prefix), so those are the wrong screens — the application does not appear in them at all. This was already wrong before this release; fixing it now that sign-in is in front of people. Both replacement links checked for 200.

Checks run locally

tsc -p script/tsconfig.json --noEmit clean · eslint clean (it lints changelog.json too) · prettier --check clean · markdownlint shows 69 violations before and after, so no new ones (the file has a large pre-existing baseline and it is not in CI).