Project-to-channel binding on kind:30617 has three reader spellings and no writer

## Problem

The project-to-channel binding on a kind:30617 repo announcement has **three reader spellings and no writer**. Every surface that renders it is therefore dead for any project created through Desktop.

All references below are at `origin/main` = `047533c56c2a2d03f23ef3edb990e58405767aac`.

## Three spellings

| Consumer | Tag it reads | Location |
|---|---|---|
| Desktop | `h`, falling back to `project-channel` | `desktop/src/features/projects/hooks.ts:213-214` |
| Web | `buzz-channel` | `web/src/features/repos/use-repos.ts:34` |
| Relay (git transport read gate) | `buzz-channel` | `crates/buzz-relay/src/api/git/transport.rs:447` |
| Relay (push policy) | `buzz-channel` | `crates/buzz-relay/src/api/git/policy.rs:303` |

Desktop and the relay disagree. A repo announcement carrying `buzz-channel` is authoritative for git read/push authorization but invisible to Desktop; one carrying `h` is visible in Desktop but ignored by the relay's access control.

## No writer

`useCreateProject.ts:52-66` builds the announcement tag list — `d`, `name`, `description`, `clone`, `web`. No channel tag in any spelling.

`buzz repos create` (`crates/buzz-cli/src/commands/repos.rs:216`) calls `buzz_sdk::build_repo_announcement`, whose signature (`crates/buzz-sdk/src/builders.rs:834-841`) takes `repo_id`, `name`, `description`, `clone_urls`, `web_url`, `relays` — no channel parameter, and no CLI flag to supply one.

Searching the tree for writers of any of the three spellings outside test fixtures returns nothing. `hooks.ts:207-212` states this outright in a comment: these are *"read-side tolerance for extension tags no code writes today (the write path that emitted them was removed)."*

## User-visible effect

- `ProjectDetailScreen.tsx:862` renders an **"Open Discussion"** button gated on `projectChannelId`. It never appears.
- `projectLabels.ts:4` labels every project **"No discussion"**.
- `VISION_PROJECTS.md` documents `buzz-channel` as the binding and describes branch-channel workflows built on it. The documented tag is the one Desktop does not read.
- Git read authorization already depends on this binding (`transport.rs:419` denies on a missing/malformed one), so operators who need repo-level access control have to hand-craft the event.

## What I think the fix is

Not asking for a feature — asking to converge on one spelling and give it a writer:

1. Pick a canonical tag. `buzz-channel` is the one the relay enforces and `VISION_PROJECTS.md` documents, so it's the obvious winner; Desktop's `h` reader is the outlier. (`h` is also NIP-29's channel tag, so reusing it on a 30617 is arguably a collision.)
2. Add the parameter to `build_repo_announcement` and a `--channel` flag to `buzz repos create`.
3. Add the field to Desktop's create-project path, and keep the old spellings as read-side fallbacks so existing announcements don't break.

Happy to send a PR for any or all of it if the direction is agreed — I'd rather confirm the canonical spelling with maintainers first than pick one and be wrong.

## Context

Surfaced while reviewing #3375 (issue board), whose cards render the channel binding. It's a pre-existing gap rather than anything wrong with that PR, but it means the affordance can't be demonstrated. Related: #2934.

First read the tag consumers in desktop/src/features/projects/hooks.ts, web/src/features/repos/use-repos.ts, and crates/buzz-relay/src/api/{git/transport.rs,git/policy.rs}; then inspect useCreateProject.ts, crates/buzz-cli/src/commands/repos.rs, and crates/buzz-sdk/src/builders.rs. Confirm the canonical spelling with maintainers before changing the readers and writers. Done means project creation can write the binding consistently and existing fallback spellings remain readable across Desktop and Relay.

Written by the indexing model from the issue text.