buzz social publish treats --content - literally, returns accepted, and cannot delete the bad note

## Summary

`buzz social publish --content -` accepts the command and returns `accepted:true`, but `social publish` does not implement the stdin sentinel supported by `messages send`. It publishes a literal one-character `-` note instead of the piped content.

The bad note then cannot be removed with the CLI because `buzz social` has no note/event delete command.

This is a silent-success failure: the caller receives a successful publish result while the intended body is discarded, and there is no CLI recovery path.

## Reproduction

```bash
printf '%s' 'expected multiline note body' | buzz social publish --content -
```

Observed publish result reported `accepted:true` with event:

```text
9eb212214efb544213c7150a7d5f92e180b5be9a166f31639e7ce46494198186
```

Canonical readback:

```json
{
"content": "-",
"id": "9eb212214efb544213c7150a7d5f92e180b5be9a166f31639e7ce46494198186",
"kind": 1
}
```

The intended body was hundreds of characters; the persisted content length was 1.

## CLI inconsistency

`buzz messages send --help` documents:

```text
--content Message text ... Use '-' to read from stdin
```

`buzz social publish --help` only says:

```text
--content Text content of the note
```

The same top-level CLI therefore assigns different semantics to the identical `--content -` shape without rejecting the unsupported form.

`buzz social --help` currently exposes publish/read/contact/list operations but no delete command, so the malformed kind-1 note cannot be retracted from the stock CLI.

## Expected behavior

One of:

1. `social publish` supports `--content -` exactly like `messages send`, or
2. it exits nonzero with an explicit “stdin content is unsupported” error instead of publishing `-`.

Also, the CLI should expose deletion/retraction for a caller-owned social note.

## Suggested fix

- Reuse the stdin content reader used by `messages send` for `social publish`.
- Add a regression test that pipes multiline UTF-8 content, then reads the event back byte-for-byte.
- At minimum, warn or reject when `--content -` is used with piped stdin.
- Return the published content length (or another readback-friendly receipt) so a one-character result is visible.
- Add `buzz social delete --event ` using the project’s normal authorized NIP-09 deletion path.

Start with the `buzz social publish` and `buzz messages send` entry points, comparing how each handles `--content -`; reproduce the piped multiline-content case. Add a regression test that reads the published event back byte-for-byte, and investigate the existing authorized NIP-09 deletion path for the requested `buzz social delete --event ` behavior.

Written by the indexing model from the issue text.