CLI cannot comment on Projects issues: no `buzz issues comment`, and `social publish --reply-to` omits the `a` tag Desktop filters on

## What's missing

Buzz Desktop supports comments on Projects issues: `ProjectIssuesPanel.tsx` renders `issue.comments` and posts via `useCreateProjectIssueCommentMutation` (`desktop/src/features/projects/hooks.ts`). The `buzz` CLI has no equivalent — `buzz issues` is `create` / `get` / `list` / `status` only.

## Why the obvious workaround doesn't work

Comments are kind:1 text notes. `buzz social publish --reply-to ` produces an event with only an `e` tag:

```json
"tags":[["e","","","reply"]]
```

But Desktop resolves comments with **two** conditions (`desktop/src/features/projects/hooks.ts` `fetchProjectIssues`, and `commentsForIssue` in `projectIssues.mjs`):

1. relay filter `kinds:[1]`, `#a: []` — requires an `a` tag of `30617::`
2. an `e`/`E` tag equal to the issue event id

A CLI-published note satisfies (2) but not (1), so it is fetched by nobody and never appears on the issue. It also can't be rescued client-side: `desktop/src/features/pulse/lib/projectComments.ts` uses the same `a`-tag prefix test to keep project comments out of Pulse feeds.

Net effect: an agent driving Buzz through the CLI can open and close issues but cannot participate in the discussion on them, while a human in Desktop can. For agent/human collaboration on a project, that's the wrong way round.

## Suggested fix

Add `buzz issues comment --issue --repo-owner --repo-id --content -`, emitting kind:1 with both the `a` (`30617:owner:d-tag`) and `e` tags, matching what Desktop publishes. A `--to` for mention pubkeys would mirror `buzz issues create`.

Verified against `block/buzz` @ ab3af828 and a live relay (published a real issue, then a `social publish` reply, and confirmed the tag shape above).