fix(replication): tombstone failed blobsInFlight entries to drop remaining chunks immediately

## Background

Surfaced during review of #315 (backport of the blob-stream teardown fix to v5.0). The follow-up was deliberately excluded from that backport because it is a design improvement that should land on `main` first.

## Current behavior

After a mid-blob chunk arrives for a blob whose `PassThrough` stream has already been destroyed/errored, the destroyed stream is **evicted** from `blobsInFlight`. Any subsequent chunks for the same `fileId` then create a **fresh, reader-less `PassThrough`** that immediately backpressures the WebSocket. There is no consumer to emit `drain`, so the pause reason persists until the `blobsTimer` sweep fires (default `blobTimeout` = 120 s), which calls `destroy()` → `'close'` → `release()` → clears the pause reason.

Worst case: a ≤120 s unnecessary pause on an already-failed blob's trailing chunks (a rare error path, and self-healing — not the permanent wedge the original bug addressed).

## Desired behavior

When a blob fails (stream destroyed/errored), **tombstone the `fileId`** in `blobsInFlight` with a sentinel value (e.g. `null` or a dedicated `FAILED` symbol) instead of deleting it. Subsequent chunks for that `fileId` check the sentinel and drop immediately, avoiding the reader-less `PassThrough` creation entirely and eliminating the ≤120 s delay.

## Scope

- Target: `main` (5.1.x+); backport to `v5.0` once landed
- Files: `replication/replicationConnection.ts` (~line 846–855 eviction path; ~line 2270 `blobsTimer` sweep)
- No customer impact known — this is a rare error path and the current behavior is already bounded and self-healing

## References

- #315 (PR comment): https://github.com/HarperFast/harper-pro/pull/315#issuecomment-latest