feat(host): check project access and refuse peers without it

[iamnbutler]

Fixes #507
Fixes #508
Part of #506. Stacked on #512 (docs).

Data model: the directory gets a shares table through a versioned migration, the first version key it has. The original CREATE TABLE IF NOT EXISTS schema becomes migration 1, so existing directories upgrade in place. GET / now returns shares, and POST /shares adds or removes one.

Access check: apps/host/src/access.ts

• Direct access:
  • GitHub read access to the project's repository, checked with the deciding host's own gh, or
  • the project is a folder on the person's own host.
• Through a share: with the team (*) or with the person, by Tailscale login.
• GitHub check details:
  • A public repository is readable by everyone.
  • The host's own account counts if it can read the repository.
  • Anyone else needs a collaborator permission other than none. GitHub only returns that to accounts with push access (verified against the real API), so a host whose owner only has read access can't confirm teammates. They need a share.
  • Answers are cached for 5 minutes, and a failed check refuses access for 1 minute.
• Sharing: only people with direct access can share or unshare.

Enforcement on the host that runs the channel: apps/host/src/gateway.ts

• Each peer's listing, the reply to channels and every broadcast, is filtered for the peer's person. The host's owner on another of their machines still sees everything.
• Peer channel requests (watch, say, ask, stop, and the rest) and peer project-repo are refused for projects without access.
• When shares change in the directory, the host resends filtered listings to peers and ends watches that lost access.
• Peer listings are also resent when a peer's GitHub login arrives late.

New ops:

• project-access: who can see a project and why, plus whether the owner can share it. Owner only.
• project-share: owner only. Writes to the directory, then sends shares-changed to every reachable peer, which re-reads the directory. A lobby can't reach someone who was just given access.
• The UI and CLI for these come in the Share a project with the team or a person #510 PR.

Smoke-tested:

• wrangler dev directory, upgrading an existing database created by main's code:
  • existing hosts and channels kept;
  • share add, remove and validation;
  • restart with migrations already applied;
  • main's code still reads the migrated database.
• github.readable against the real API:
  • public repo;
  • private repo as the owner;
  • private repo as a non-collaborator;
  • a repo that doesn't exist.
• access.ts against that directory, with this host's real gh:
  • own folder vs another host's folder;
  • a share for a person;
  • a team share;
  • refusal to share another person's folder;
  • unshare.
• A --loopback host boots and lists channels.

Not exercised (needs two people on two Macs): peer listing filtering, refused peer channel requests, and revoking watches when a share is removed. These are in the study scenarios.

Built in Ace

No. Built with Claude Code in a terminal: the session that planned #506 continued straight into implementation, and smoke tests ran wrangler dev and the gh CLI directly. Nothing here needed a capability Ace lacks.