fix: keep Linux remotes out of the device pool and offer them in build suggestions

[janicduplessis]

Description

Depends on #3647 (stack: #3610 -> #3618 -> #3621 -> #3631 -> #3638 -> #3639 -> #3647 -> this).

A Linux remote could count as a device-pool member it can never satisfy. validateAutomaticPool('device', …) accepts any configured remote with an approved device-host credential, and hostingMachines() hands every asked machine to automatic placement. A Linux machine can hold such a credential: a Linux stim-server accepts device-host requests, and stim-server devices grant <id> --device-host has no platform check (only setup refuses --device-host there). Before #3639, stim doctor --fix also asked Linux machines for device-host access. So stim settings set remote.devicePoolDisabled '["local"]', or turning off Simulators enabled for This Machine in Desktop, succeeded while the only remaining member could never host. Every --remote auto run then refused, and the Linux row no longer shows its Simulators toggle (#3647).

Desktop's build suggestions ignored Linux peers. DiscoveryCoordinator read only online macOS peers, so the new-peer and build-slot-wait suggestions never offered a Linux machine, although the wizard can add one.

Solution

CLI. Core's cannotHost(status, entry) says whether tailscale status reports the peer as running an OS other than macOS; an unknown OS (no status, peer missing, no OS) counts as able to host. It is applied in three places:

• Pool validation. validateAutomaticPool takes a canHost predicate for the device role, and writeConfigSetting passes it. It reads tailscale status before taking the config lock, and only when the write leaves local out of the device pool, the one case where validation looks at remotes.
• Placement. hostingMachines(), used by automatic and planned placement, drops those machines, so they are never probed or chosen.
• Doctor. inspectDeviceHostMachines uses the same helper and now applies it even to a saved approval. Such a machine is neither contacted nor reported as approved: it shows not-asked with no finding, and the credential stays on disk. Desktop therefore never sees an approved Linux host, so its device-limit "Use Auto" prompt and its Simulators pill cannot name one.

The build pool is unchanged. I did not make the Linux server refuse device-host requests or grants: an existing approval on any server version would still need the client-side check, which this PR adds.

Desktop. DiscoveryCoordinator reads Tailnet.buildPeers (online Macs and Linux machines). The new-peer suggestion uses all of them; the build-slot suggestion preselects a Linux machine only when an Android build waited, since an iOS build cannot go there. Discovery.capHit now takes the peers and preselects only a Mac, so the device-limit suggestion stays Mac-only. With only a Linux peer it says "another Mac" and preselects nothing. The seen-peers baseline moves to a new defaults key (discovery.seenBuildPeers): the old one held only Macs, so reusing it would announce every long-present Linux node as having just joined. The first poll after the upgrade records a fresh baseline without prompting.

Test plan

• settings-command.test.ts:
  • With a device-host-approved box that tailscale status reports as linux, stim settings set remote.devicePoolDisabled '["local"]' exits 1 and writes nothing.
  • The same machine reported as macOS is accepted.
  • tailscale is stubbed through the executor.
• device-host-machines.test.ts:
  • hostingMachines drops a peer reported as linux and keeps it when the status is unknown.
  • Doctor neither contacts nor reports as approved a saved approval for a peer reported as linux.
• The hosted iOS and Android client tests stub realIo.status, so no test runs the real tailscale binary.
• DiscoveryTests: the device-limit suggestion skips a Linux peer and picks the Mac when both are online; the build-slot suggestion picks the Linux peer after an Android wait and the Mac after an iOS wait.
• Desktop built and launched with stim macos; stim logs --errors was empty. The screen was still locked, so there are no new window screenshots; the suggestion banners are unchanged visually.

Fixes #3649