test(rustd): Dimensions 4.1 and 4.3, the two with no coverage at all

Auditing the spec's 25 dimensions against the tree found two that no test
touched. Most of the 18 spec-named tests that appeared "missing" exist under
prose-style names the implementer chose; these two did not exist at all.

Dimension 4.1 — the live tail. `integration_runner_activity.rs` drives it over
real HTTP against the booted daemon with a `SubscriptionHub` — the production
subscriber the dashboard runs on, not a raw SUBSCRIBE — listening while the
request is in flight. A well-formed chunk answers 202 and arrives once, renamed
to `chunk` and stamped with the EVENT id; an unknown frame kind answers 400 and
publishes NOTHING, which is what proves the body is read before the lease is
loaded; a lease this runner does not hold answers 404 and publishes nothing.

Dimension 4.3 — memory capture fencing. `integration_memory_capture.rs` writes
with the live fence first, because without an entry to overwrite a refused write
and a write that silently did nothing look identical from the store's side. Then
`fence - 1` earns `UZ-RUN-005`, and the store is read back through `hydrate`:
one entry, the holder's content, under the same key. Both writes use ONE key
deliberately — `(key, fleet_id)` is the upsert's conflict target, so a leaked
write would OVERWRITE and a count-only assertion would pass while the content
had been replaced. Two siblings pin the other edges: a token ABOVE the live
sequence is admitted (the reason the comparison is `<` and not `!=` — a reclaim
bumps the sequence, so the current holder can legitimately be ahead), and a
lease the runner does not hold answers `UZ-RUN-006` rather than a fence error.

`Redis::unreachable` is added behind `test-util`, mirroring `Db::unreachable`
exactly. The lane's Redis is SHARED by every test binary cargo runs in parallel,
so pausing the container, killing the server or dropping the port would fail
unrelated suites at the same instant; a lazy handle one test owns fails only its
own commands. That is what lets `integration_activity_publish.rs` prove the real
claim — a `Plane` over LIVE Postgres and a dead Redis returns Ok, because a
runner counts consecutive rejections toward self-termination and telemetry
answered as a refusal walks healthy hosts to shutdown. Live-Postgres-dead-Redis
is also the only composition that REACHES the publish; both gone would refuse at
the first row read.

`publish_activity` has TWO drop branches, not one. The frame it cannot render
and the queue that will not take it are separate code paths with the same
outcome, and both are covered rather than one standing in for the other — the
HTTP-level one is named `test_activity_drops_a_frame_it_cannot_render` to say
which it is.

Also fixes a flake this session introduced: `assert_shape` read through
`fetch_optional` with no ORDER BY, and two of its predicates legitimately match
more than one row — a runner writes a narrative row at enrolment and another at
claim. It was asserting against whichever row Postgres happened to return, which
is a test that passes until it does not. Ordered by `created_at, id` now; `id`
breaks the tie because `created_at` is a millisecond and two rows can share one.

Integration lane: 105 passing, 0 failing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>