fix: return batch children in creation order, and start jobs pending, in MemoryStore

[GautamSharma99]

Fixes #56.

Two commits. The first is the reported bug; the second is a second divergence the new contract suite found, kept separate so it can be dropped independently if you'd rather see it on its own.

1. Child ordering (4429aa4)

MemoryStore.GetChildJobs ranged over the job map and returned whatever order Go's randomised iteration produced, while PostgresStore orders by created_at. GetBatchJob turns that order into each result's index, so in the DB-less mode the README leads with, polling the same batch twice returned the results — and the response's own urls list — in different orders.

MemoryStore now records an insertion sequence and sorts on it.

Why the sequence rather than CreatedAt, which the issue suggested: time.Now().UTC() strips the monotonic clock reading, so the stored timestamp is wall-clock only. That makes it subject to NTP adjustment, and on platforms with coarse resolution it ties outright for batch children created in a tight loop — which is exactly how they're created (scraper.go). The sequence is assigned inside the same critical section as the insert, so it is creation order, with no tie-break needed.

Storing it needs a small wrapper around the record, which is why the other methods change shape. None of their behaviour does.

2. Jobs now start pending (860b25c)

internal/store had no tests at all, which is how the ordering divergence survived. This adds the shared contract suite I offered in the issue — the same assertions run against both implementations.

It immediately found a second one. PostgresStore.CreateJob inserts the literal 'pending'; MemoryStore copied the caller's JobRecord, and no caller sets Status, so jobs were stored with "".

That is not cosmetic:

• UpdateParentBatchStatus counts children by status, and "" matches neither the pending nor the processing branch
• so pending == total is false, pending > 0 || processing > 0 is false, and the parent falls through to the completed branch with CompletedAt stamped
• GetBatchJob derives the response status the same way

In DB-less mode a batch therefore reported completed the moment it was submitted, before any child had run. GET /v1/url-scraper/:id also returned "status": "" for a queued job.

MemoryStore now sets pending on create, matching Postgres — which hardcodes it and ignores the caller's value, so the contract is "a new job starts pending" in both.

Verification

Both new tests fail on the previous implementation:

--- FAIL: TestMemoryStore_ChildOrderIsStableWithoutTimestampGaps
    memory_test.go:54: attempt 0: children[1].URL = "https://example.com/2", want "https://example.com/1"
--- FAIL: TestContract_GetChildJobsReturnsCreationOrder
    store_contract_test.go:161: attempt 3: children[0].URL = "https://example.com/2", want "https://example.com/1" — order is not creation order

The contract suite was run against a real database, not just the memory backend:

$ docker compose up postgres -d
$ TEST_DATABASE_URL="postgres://postgres:postgres@localhost:5432/anakinscraper?sslmode=disable" \
    go test -race -v -run TestContract ./internal/store/

--- PASS: TestContract_CreateAndGetJob
    --- PASS: TestContract_CreateAndGetJob/memory
    --- PASS: TestContract_CreateAndGetJob/postgres
--- PASS: TestContract_GetChildJobsReturnsCreationOrder
    --- PASS: TestContract_GetChildJobsReturnsCreationOrder/memory
    --- PASS: TestContract_GetChildJobsReturnsCreationOrder/postgres
... 9 contract tests, both backends
ok      .../internal/store  1.650s

Without TEST_DATABASE_URL the Postgres half skips with a logged note, so go test ./... stays green on a machine with no database and CI is unaffected. If you'd like it wired into CI, adding a postgres:16-alpine service to .github/workflows/ci.yml and setting the env var is a couple of lines — happy to add that here or separately.

Coverage: internal/store 0% → 50.9%.

Full CI parity locally — gofmt -l clean, go build ./..., go vet ./..., go test -race ./... all pass.

Notes for the reviewer

• The contract suite deliberately sleeps 2ms between child creations, because backends that order on the wall clock need distinguishable timestamps. The MemoryStore-specific test creates eight children back to back with no delay, which is the case the insertion sequence exists for.
• The ordering assertions repeat 20–50 times; a single call can match a randomised order by luck.
• Expected trivial conflict with fix: preserve target HTTP status so blocked proxies take the severe penalty #59/fix: test the shipping sync-timeout clamp, and fix an overflow it hid #60/fix: apply domain config isEnabled, priority and requestTimeoutMs #61/fix: copy proxy scores under the lock instead of sharing live pointers #62 on the ## Unreleased CHANGELOG heading. Happy to rebase whichever lands last.
• MemoryStore never evicts jobs — the default zero-config mode grows unbounded until OOM #57 (MemoryStore never evicts) is still open and lands in the same file. The contract suite here would give that change a safety net; say the word and I'll follow up.