feat(api): add count param to /dlq/reprocess (CON-575)

[pavanputhra]

Summary

• Adds count query param to POST /dlq/reprocess to bound work per call (default 1000, max 100k).
• Converts the unbounded while ...: drain into a bounded for _ in range(count): ... loop, breaking early when the DLQ empties.
• Response shape unchanged — still returns the int count of items moved.

Linear: CON-575

Why

Today's incident: cleaning up a ~4M DLQ couldn't use this endpoint — at ~1600 items/sec sequential LPOP+RPUSH that's ~42 min of one HTTP request, well past every proxy timeout (Traefik 60s, browsers, internal LBs). The drain had to be done out-of-band via a Python sidecar using Lua LMOVE batches.

count moves the loop from server to client: each call is bounded and snappy, the client drives the drain (while r > 0: POST ...&count=10000), progress is observable per response, no timeouts.

Backward compatibility

• HTTP signature: same path/method/required-param. count is optional with default.
• Response: still JSONResponse(content=<int>).
• Existing callers without count work unchanged — they just get bounded responses.
• No internal callers in the codebase (grepped to confirm).

Test plan

• pytest common/tests/test_api_branches.py common/tests/test_api.py -v — 21 passed.
• Existing test exercising small DLQ (lpop returns "a", "b", None) still passes — falls within default count budget.
• New test asserts count=3 against an unbounded mock drains exactly 3 items.