No update path for the Linux .deb: no APT repository and in-app updater does not appear to run

### Short summary

There appears to be no working update path for the Linux `.deb`. There is no APT repository, so `apt upgrade` will never see new versions, and in practice the in-app updater does not appear to deliver updates for `.deb` installs — the same app installed as an AppImage self-updates reliably. The result is that `.deb` users must periodically check the releases page and reinstall by hand, or switch to the AppImage.

This matters because the AppImage has its own problems (see #3060: it forces `GDK_BACKEND=x11` and bundles a conflicting glib), so users currently have to choose between **working updates** and **working rendering**.

### Affected version or release

`1.1.11` (`.deb`)

### Installation context

`.deb`

### What happened?

**No APT repository**

```console
$ grep -rl -i "copilot\|githubapp" /etc/apt/sources.list /etc/apt/sources.list.d/
# (nothing)
```

So there is no channel for `apt upgrade` / `unattended-upgrades` to use.

**AppImage self-updates; the `.deb` session shows no updater activity**

Comparing app logs on the same machine, same day. AppImage session (updater engages seconds after startup, full cycle):

```
2026-08-21T06:26:33 INFO github_app::platform::updater: Update available current_version="1.1.10" version="1.1.11"
2026-08-21T06:26:35 INFO github_app::platform::updater: Downloading update version=1.1.11
2026-08-21T06:27:07 INFO github_app::platform::updater: Update download finished
2026-08-21T06:27:09 INFO github_app::platform::updater: Update staged, waiting for user to restart
2026-08-21T06:54:50 INFO github_app::platform::updater: Staged update installed, restarting app version=1.1.11
```

`.deb` session, running ~90 minutes:

```console
$ grep -ci "updat" ~/.copilot/logs/github-app..log
0 # out of 556 log lines
```

**What I could not determine**

I want to be careful not to overstate this. The binary does contain updater code paths that look capable of elevating on Linux — strings include `Enter your password to install the update`, `pkexec`, `kdialog`, and `ReleaseManifestPlatform`. So the capability appears to exist.

Because `1.1.11` was the latest release at the time of testing, I cannot distinguish between:

- the updater being gated off for `.deb` builds, versus
- the updater checking, finding nothing, and simply not logging a no-op check.

What I can say is that the AppImage logs an update check promptly on startup while the `.deb` session logged nothing at all, and that as a user this has consistently not worked — the original reason I moved from `.deb` to AppImage was that `.deb` updates never arrived.

### Steps to reproduce

1. Install the `.deb` while a newer release exists.
2. Run the app and leave it open.
3. No update is offered, and no updater lines appear in `~/.copilot/logs/github-app..log`.
4. `apt upgrade` also never offers it, as no APT source is configured.

### Expected behavior

`.deb` installs should have some supported update path. In rough order of preference:

1. **Publish an APT repository.** This is the idiomatic answer for `.deb` distribution: it integrates with `apt upgrade` and `unattended-upgrades`, keeps the package manager as the source of truth, and needs no privilege elevation from the app itself. It's what Chrome, VS Code, and Docker do.
2. **Enable the in-app updater for `.deb`**, using the polkit prompt that already appears to be present, so the app can install a newly downloaded package with elevated rights.
3. **At minimum, notify.** Even without installing anything, showing "a new version is available — download here" would remove the need to poll the releases page manually.

If option 2 is chosen, please also fix #3065 first: the published `.deb` currently installs its files owned by `runner:runner` (uid 1001) rather than `root:root`, so any update that reinstalls the package will keep reintroducing that ownership.

### Additional context

The practical effect of this plus #3060 is that Linux users are pushed toward whichever set of defects they mind least:

| | AppImage | `.deb` |
| --- | --- | --- |
| Auto-updates | works | no observed path |
| Display backend | forced `GDK_BACKEND=x11` (#3060) | native Wayland |
| Compositing | software readback | GPU / DMA-BUF |
| Bundled glib conflicts | yes (#3060) | no |
| File ownership | n/a | `runner:runner` (#3065) |

Fixing the update path for `.deb` would make it a clean recommendation for Linux, which would in turn make the AppImage's issues much less pressing.

### Environment

| Field | Value |
| --- | --- |
| App version | 1.1.11 (`.deb`), compared against 1.1.9/1.1.10/1.1.11 AppImage sessions |
| OS | Ubuntu 24.04.4 LTS, GNOME 46 Wayland |

Start by tracing the Linux updater paths referenced in the report, including ReleaseManifestPlatform, and compare the .deb startup behavior with the AppImage log sequence. Check how .deb installation, pkexec, and the existing update notification paths are connected. Done means a supported update path is documented and verified for .deb installs, with #3065 considered if package replacement is used.

Escrito por el modelo de indexación a partir del texto del issue.