In-app updater security and supply-chain risk mitigation.

## Summary

The published app now has an in-app update path, so the updater is part of the distribution trust boundary. The current implementation is a good start, but it accepts the first release asset whose name ends in `.zip` and verifies the extracted app primarily by matching `TeamIdentifier` with the currently running app.

This is worth hardening before the updater becomes widely used. I do not see evidence that the current `v0.5.7` release asset is tampered with: the zip SHA matches the Homebrew cask, the app is Developer ID signed, has hardened runtime, and is notarized. This issue is about reducing supply-chain risk in future updates.

## Current behavior

- `UpdateChecker` selects the first release asset ending in `.zip` instead of requiring an exact expected asset name.
- `Installer` unzips the downloaded archive and picks the first top-level `.app` it finds.
- Signature validation compares only `TeamIdentifier`, then runs `codesign --verify --deep --strict`.
- Quarantine is stripped before the full verification/replacement flow completes.

Relevant code paths:

- `Sources/WhatCable/UpdateChecker.swift`: release asset selection via `.hasSuffix(".zip")`
- `Sources/WhatCable/Installer.swift`: `unzipAndLocate`, `stripQuarantine`, and `verifySignatureMatches`

## Why this matters

`TeamIdentifier` is broader than this specific app. In a compromised release workflow, wrong uploaded asset, or future multi-asset release, the updater should reject anything that is not exa...