feat: add a queue reset so a repeated push cannot enqueue work twice

[beagleknight]

Problem

A backend spec failed in factorial CI with a T::Struct prop redefinition error. It looked like a Sorbet/Tapioca problem. It was not: the same spec file was loaded twice in one process.

The queue key is scoped by CI run, not by CI attempt. That is deliberate. Re-running a single failed runner does not re-run the job that pushed, so the runner must still find the queue and the published marker that the first attempt created.

The cost is that the producer is not idempotent:

• A producer that pushes and then fails leaves the work list orphaned, because its runners never start.
• A producer that runs again (whole-workflow re-run, or a failed-jobs re-run that includes it) appends a second copy on top.

Every file is then enqueued twice. The suite runs twice, and any two copies that reach the same worker are loaded twice in one process. For test files that define constants at file scope, the second load is fatal.

Change

RedisQueue#clear removes the queue and its <key>:published marker in a single DEL. It is exposed two ways:

specbandit push --key KEY --reset    # empty the key, then push
specbandit reset --key KEY           # standalone

Reset is opt-in. push keeps its current meaning and appending to a queue stays possible.

What reset does not touch

Per-runner rerun keys and failed keys. A runner's replay memory has to survive a re-run of that runner. A runner that finds data in both the shared queue and its rerun key is the full-rerun case, already handled in v1.2.0: it resets its own memory and steals.

Nothing is cleared when there is nothing to push in its place. Dropping the marker on its own would make every worker on that key crash as "never published".

Tests

• RedisQueue#clear issues one DEL with both key names.
• Publisher: clear happens before the push, only with reset: true, never on an empty push, and the leftover count is reported.
• Integration, against a real Redis: two plain pushes leave 14 entries, a third push with --reset leaves 7 and the marker survives.

Also fixes a leak in the existing failed-key integration test, which deleted <key>-failed but not its :published marker, so every run left a key behind.

Follow-up, not in this PR

The flaky-retry pass consumes <key>-failed-<n>, which is written by work, not push, so a re-run can still leave stale entries there. The blast radius is re-running an already-failed spec, not a double load.

Next

Needs a Release dispatch (bump: minor → v1.3.0) before factorial can adopt it. The npm package needs the same change; that PR is separate.