bug: verifier queue drain stalls on runtime queue payloads

[pureliture]

Outcome

The DB-backed verifier queue drains reliably against runtime DynamoDB payloads and remains isolated from the code-scan worker.

Scope

• Normalize DynamoDB-deserialized numeric fields before verifier prompt construction so redacted finding snapshots are JSON-serializable.
• Keep job_type="verify" jobs owned by verify-drain; code-scan workers must not lease or rewrite verifier jobs.
• Preserve the public-safe boundary: no raw secrets, repository names, paths, or live finding data in tests or diagnostics.
• Operational follow-up after merge: deploy the fix to the runtime checkout and set verifier HTTP timeout high enough for the configured model latency.

Acceptance Criteria

• Finding.from_dict() restores numeric location fields from DynamoDB-compatible values into plain Python primitives.
• lease_next_scan_job() skips verifier jobs, while lease_next_verify_job() still leases them.
• Regression tests cover DynamoDB Decimal verifier snapshots and scan-worker/verifier queue isolation.
• A bounded live drain can process verifier jobs without retrying due to serialization failure or scan-worker contention.

Bug Details

Actual behavior:

• Historical verifier backfill enqueues verifier jobs, but drain attempts retry instead of consuming the queue consistently.
• Runtime inspection showed one failure path from Decimal-backed finding snapshots during prompt JSON serialization.
• The code-scan worker can also lease job_type="verify" jobs and return them to pending, overwriting verifier job error state and competing with verify-drain.

Expected behavior:

• Verifier jobs are drained only by verify-drain.
• Runtime finding snapshots deserialize into prompt-safe domain objects.
• Queue status moves from pending verifier jobs to completed/terminal disposition outcomes without code-scan worker interference.