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 |

首先跟踪报告中引用的 Linux 更新器路径，包括 ReleaseManifestPlatform，并将 .deb 的启动行为与 AppImage 的日志序列进行比较。检查 .deb 安装、pkexec 和现有更新通知路径之间的连接方式。对于 .deb 安装，完成受支持的更新路径的文档编写和验证即表示完成；如果使用软件包替换，则需要考虑 #3065。

由索引模型根据 Issue 内容生成。