testing: flexiq dev, an in-memory server with a fake clock

Testing code that enqueues means either running a real queue or mocking the client. The Java SDK
has test-support and an InMemoryFlexiQ; the other two shells have neither, so each user
invents their own fake and each fake is wrong in a different way.

Build the harness once, behind the wire, so every language gets it:

flexiq dev — a single binary that serves the producer and executor doors against in-memory
storage, plus the things a test needs and a production server must never have:

• A fake clock. Advance time explicitly. Retry backoff, visibility timeouts, step.sleep,
  periodic schedules and debounce windows are all clock-driven, and a test that asserts on any
  of them currently sleeps.
• A drain-to-quiescence call. "Run everything that is runnable, then return." Deterministic,
  and it removes the join-budget problem that has now caused two separate outbreaks of
  copy-pasted timeouts across the test suites (#809, and the Node waits before it).
• Assertions over the wire — jobs enqueued, with what arguments, in what order, and what
  each one did.
• Ephemeral by construction. No file, no port collision, deterministic teardown. On Windows
  a temp SQLite file cannot be deleted while a handle is open, and no SDK exposes a storage
  close() — in-memory sidesteps that entirely.

Because it is a gRPC server, a Go or Ruby client gets the same harness on the day it is written,
with no work in this repository. That is the argument for building it here rather than three
times in three shells.

Start by reading the Java SDK's test-support and InMemoryFlexiQ, then inspect the producer and executor doors described in the issue. Define the wire-level behavior for fake-clock advancement, drain-to-quiescence, job assertions, and ephemeral teardown. Done means the single flexiq dev binary provides these deterministic in-memory testing capabilities without files or port collisions.