relay_admin_actions::execute_delete_with_marker updates reply_count on the wrong table (events, not thread_metadata) and skips descendant_count

## Summary

`execute_delete_with_marker` in `crates/buzz-db/src/store/relay_admin_actions.rs` (around line 747) runs, when a moderation-triggered delete has a known parent:

```sql
UPDATE events
SET reply_count = GREATEST(reply_count - 1, 0)
WHERE community_id = $1 AND id = $2 AND deleted_at IS NULL
```

The `events` table (defined in `schema/schema.sql`, `CREATE TABLE events (...)` starting around line 203) has no `reply_count` column at all — that column lives on `thread_metadata` (`schema/schema.sql` around line 522-523, `CREATE TABLE thread_metadata (...)`). Running this query against a real Postgres database would fail with "column \"reply_count\" does not exist."

By contrast, the two other call sites that maintain the same counters both target `thread_metadata` correctly:
- `crates/buzz-db/src/store/thread.rs` (`increment_reply_count`/`decrement_reply_count`, ~line 256-321)
- `crates/buzz-db/src/store/event.rs` (`soft_delete_event_and_update_thread` ~line 897-931, and the reply-insert path inside `insert_event_on` ~line 1296-1309)

Those two also update `descendant_count` on the thread root when one exists; `execute_delete_with_marker`'s branch does neither — it never touches `descendant_count`, and its `_root_event_id` parameter is prefixed `_` (unused), so a moderation delete of a reply currently leaves the root's `descendant_count` un-decremented even if the table-name bug is fixed.

## Why CI hasn't caught this

The only test exercising this function, `crates/buzz-relay/src/api/admin/mod.rs` (~line 5002), calls it with `parent_event_id: None` ("no parent"), which skips the `if let Some(parent) = parent_event_id` branch entirely — so the broken query has never actually executed in any test run.

## Impact

A moderator/operator deleting a reply through the relay admin action path (`report_resolution.rs` → `execute_delete_with_marker`) with a known parent would currently error out (or, if the query were "fixed" to target the right table without also touching `descendant_count`, would silently leave the thread root's descendant count too high).

## Suggested fix

Point the `UPDATE` at `thread_metadata` (matching the WHERE clause shape used by `thread.rs`'s `decrement_reply_count`), and add the matching `descendant_count` decrement for `root_event_id` when known — mirroring the two other call sites exactly, plus a test that actually exercises the `Some(parent_event_id)` branch.

## How this was found

Found incidentally while gathering evidence for launchpad-26/buzz#955 (a corpus documentation task about recognizing recurring code patterns) — the exercise of tracing every place that maintains `reply_count`/`descendant_count` surfaced this inconsistency. Not fixed here; filing per this fork's own routing rule that genuine product bugs belong at `block/buzz`, not the fork's own issue tracker.

Start in crates/buzz-db/src/store/relay_admin_actions.rs around execute_delete_with_marker, then compare the counter updates in thread.rs and event.rs and the events/thread_metadata definitions in schema/schema.sql. Extend the existing admin test in crates/buzz-relay/src/api/admin/mod.rs to exercise parent_event_id: Some(...); done means the moderation delete updates the correct metadata counters and the test covers that branch.

Written by the indexing model from the issue text.