[Meta] Show projects only to people with access #506

Today every channel is broadcast across the tailnet, whatever the project. A teammate sees every project with a channel, including private repositories they can't read on GitHub and local folders (for example toddler-game). This adds access control by project.

Rules

• Access to a project means you can see it and its channels, and read and post in them as teammates do today. There is one level. Whether teammates can invoke an agent is still decided per channel by the agent access toggle.
• You have direct access to a project if:
  • it's backed by a GitHub repository and your GitHub login can read that repository (so public repositories are open to the whole team), or
  • it's a local folder on your own Mac.
• A share gives access to the whole team or to one person, on top of GitHub. It opens the whole project: every person's channels in it, now and later. Forking a channel into a project of your own is how you keep work out of a shared project.
• Only people with direct access can share or unshare a project. Access through a share can't be passed on.
• The confirmation names whose channels the share exposes. For example: "Share starship with Alex? Alex will see every channel in it, including Terkel's and Luke's, and any created later."
• On upgrade, existing projects become private. People with GitHub read access keep seeing repository projects. Local folders disappear for everyone else until someone shares them.

Enforcement (cooperative)

Access holds between hosts running unmodified Ace:

• The host that runs a channel names each caller with tailscale whois. It refuses people without access, so local channel transcripts, diffs, and repository info never leave it.
• Each host shows its owner only projects the owner can access. That covers the directory's listings, lobby subscriptions and events, and hosted channels.
• Shares live in the directory, the team's shared cell. Every host reads them there, because a share has to apply to everyone's channels in the project, not only the sharer's.

Known security hole

This is not a boundary against a teammate who tampers with Ace:

• The directory, lobbies, hosted channels, and compute service accept one team credential derived from ACE_SECRET, which every host holds. Anyone who copies ACE_SECRET can:
  • read every listing: channel names, summaries, and absolute project paths;
  • join any project's lobby;
  • watch and post in any hosted channel;
  • read and rewrite the share list.
• Lobby names for local folders contain the host and path.
• A peer host reports its owner's GitHub login from its own gh CLI. Nothing verifies it, so the GitHub read-access check trusts what the peer claims. Shares are stored by Tailscale login, which whois verifies.
• Hosts on older versions don't enforce access. They keep serving their channels to every peer.

Closing the hole needs per-person credentials that the services verify. That's tracked in the last sub-issue.

Docs

The definition of Team in docs/terms.md and the section "The team" in docs/architecture.md say Ace has no team access controls. Both change first, with new terms Access and Share.

The name clashes with ace share <channel> on|off, which is the per-channel agent access toggle. That command needs a new name, for example ace agents <channel> on|off, so that "share" refers only to project access.

Sub-issues are listed in order.

Dogfooding: #5