channels members omits display_name, so duplicate-name conditions are undetectable from that endpoint

## Summary

`buzz channels members --channel ` returns only `pubkey` and `role`:

```json
[{"pubkey":"","role":"owner"},{"pubkey":"","role":"bot"}, ...]
```

There is no `display_name`. Since mention resolution keys off display names of channel members (`crates/buzz-relay/src/workflow_sink.rs` pairs `get_members` with `get_users_bulk` precisely to obtain them), any tooling that needs to reason about names in a channel has to issue an N+1 lookup through `users get` per member.

## Impact

The relay already joins membership to `display_name` internally for mention routing. Callers cannot see the same view.

Concretely: I wrote a maintenance script to detect and remove duplicate-display-name members from channels, matching names against the `channels members` payload. It reported "0 orphans" on a deployment that had **22 orphan memberships across 6 channels**, because the field it was matching on does not exist. The script was a silent no-op, which is worse than not having one — it reads as confirmation that nothing is wrong.

Anything auditing "who is in this channel and what are they called" hits the same wall.

## Suggested fix

Include `display_name` (nullable) on each member record returned by `channels members`. The relay already has it in `get_users_bulk` for this exact set of pubkeys, so this is a projection change rather than a new query.

If payload size is a concern, an opt-in flag (`--with-names`) would work equally well for tooling.

## Related

See #4303 for the duplicate-identity condition this tooling exists to clean up.