buzz pr update: tip updates (kind:1619) are published but unreachable — no h tag, and pr get/list filter to kind:1618

# buzz pr update: tip updates (kind:1619) are published but unreachable — no `h` tag, and `pr get`/`pr list` filter to kind:1618

## Summary

`buzz pr update` correctly publishes a NIP-34 kind:1619 event, but no read path in the CLI
can surface it, and it never reaches the channel that owns the PR. A PR therefore keeps
advertising the tip commit it was *opened* at, indefinitely, no matter how many times it is
repointed.

## Impact

A reviewer who resolves a PR's code from the PR event reviews the state at open time. After
any fix-and-repoint cycle that is the **pre-fix** code — and the resulting pass looks
entirely legitimate, because nothing anywhere reports a mismatch. There is no error, no
warning, and no divergence visible in any `buzz pr` output.

The workaround is to ignore the PR event's `c` tag and resolve the tip from the branch
instead (`git ls-remote --heads refs/heads/`), but nothing in the tool
or its output suggests that is necessary.

## Reproduction

```sh
buzz pr open --repo-owner --repo-id --subject 'Example' \
--commit $(git rev-parse HEAD) --clone --branch-name example \
--channel
# -> event , tagged ["c",""], ["h",""]

# push a follow-up commit, then:
buzz pr update --repo-owner --repo-id --pr \
--pr-author --commit --clone
# -> {"accepted":true,...}, event
```

Now try to observe the new tip:

```sh
$ buzz pr get --event
# root event only; still ["c",""]

$ buzz pr get --event
[]

$ buzz pr list --repo-owner --repo-id
# kind:1618 roots only; no updates

$ buzz messages get --channel --kinds 1619
# nothing
```

The update event is not lost — it is retrievable by id, which the CLI itself demonstrates:

```sh
$ buzz messages thread --channel --event
{"error":"error","message":"event has no h-tag — cannot determine channel"}
```

To report "has no h-tag" the CLI had to fetch the event and inspect its tags. The event
exists; it is simply invisible to every path that would naturally be used to find it.

## Root cause

Verified against `origin/main` at `c3132c3e` (2026-08-31). Both files below are byte-identical
between that commit and the checkout used here.

**1. No `h` tag on kind:1619.** `GitPullRequestMeta` carries `channel_id`
(`crates/buzz-sdk/src/builders.rs:1439`), and `build_git_pull_request` emits it as an `h` tag
(`builders.rs:1506-1510`). `GitPrUpdateMeta` has no equivalent field
(`builders.rs:1533-1549`), and `build_git_pr_update` emits only
`a, r?, p, E, P, c, clone, merge-base?` (`builders.rs:1552-1592`) — never `h`.

Correspondingly, `cmd_open_pr` takes `channel: Option<&str>`
(`crates/buzz-cli/src/commands/pr.rs:35`) and forwards it (`pr.rs:49`), while `cmd_update_pr`
(`pr.rs:73`) has no channel parameter at all. So a repoint can never surface in the channel
where the PR was opened, and channel-scoped queries structurally cannot see it.

**2. Both PR read paths hardcode kind:1618.** `cmd_get_pr` filters `"kinds": [1618]`
(`pr.rs:116-121`), so it cannot return an update event even when given its exact id.
`cmd_list_prs` filters `"kinds": [1618], "#a": [...]` (`pr.rs:127-142`), so updates never
appear in a listing either.

## Suggested fix

1. Add `--channel` to `buzz pr update` and a `channel_id` field to `GitPrUpdateMeta`,
mirroring `build_git_pull_request`'s `h`-tag block. Repoints then surface in the owning
channel like the original open does.
2. Widen `cmd_get_pr` to `"kinds": [1618, 1619]`, or add a way to fetch a PR *with* its
updates so callers can resolve the current tip. Today, `buzz pr get` on a PR that has been
repointed returns a stale `c` with no indication it is stale.
3. Consider having `cmd_update_pr` print a `link` the way `cmd_open_pr` does
(`pr.rs:64-67`); it currently prints only the raw relay response.

Item 2 is the one that prevents silent mis-review. Item 1 is what makes repoints visible to
people watching the channel.

## Notes

Searched open and closed issues on `block/buzz` for prior reports of this
(`pr update channel h-tag`, `1619 pull request update`) and found none. The closest adjacent
issue is #2990 (no way to revise a published kind:1621 issue body), which is a different
surface.

Start with crates/buzz-sdk/src/builders.rs, especially GitPullRequestMeta, GitPrUpdateMeta, build_git_pull_request, and build_git_pr_update, then trace cmd_open_pr, cmd_update_pr, cmd_get_pr, and cmd_list_prs in crates/buzz-cli/src/commands/pr.rs. Done means kind:1619 updates carry the owning channel, and get/list can surface updates so a repointed PR exposes its current commit.

Written by the indexing model from the issue text.