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

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 (tests(python): worker join budgets are copy-pasted at 5s, and 20s was not enough #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.