Make inserter batch size and parallelism configurable

[ff137]

What

• Adds INSERTER_BATCH_SIZE and INSERTER_PARALLELISM (defaults 100 / 100) so operators can tune how many insert_queue rows are pulled per tick and how many insertMatch calls run at once, without code changes.
• Replaces the hardcoded LIMIT 100 with a bound LIMIT ? driven by batch size.
• Processes each tick in waves of at most INSERTER_PARALLELISM inserts (with defaults, that is still one wave of up to 100, matching previous behavior).
• Keeps the maintainer’s 10s watchdog that records inserter_timeout and process.exit(1) if a tick stalls; wraps the tick in try / finally so the timer is always cleared on success.
• Fixes the invalid Error("no match in row: %s", …) usage and logs Promise.allSettled rejections per chunk.

Why

The pain was too many concurrent inserts when the system is under load; parallelism is what sets that peak, batch size is how many rows you dequeue per tick. Exposing both as config makes it easy to lower concurrency when Postgres is saturated while defaults stay at the old 100-wide rate so ingest keeps up when healthy.

[howardchung]

I think we need the existing rate numbers to keep up with new matches. But I think there's a good point of the timeout not cancelling existing stalled inserts, so we probably need to kill the process and restart if that happens

[howardchung]

I made a separate change to kill the process on timeout. Let's see if that helps

[ff137]

@howardchung I've rebased to keep the new timeout change, and I've also updated config to preserve existing rates.

The main change now is being able to tune 2 knobs without code edits: batch size per tick, and the num parallel inserts

The batch size can be increased so more matches get pulled from insert_queue per tick, and lower the parallel inserts so that postgres pressure is reduced. I think that's the direction to go down -- keep total matches per batch high, while reducing concurrent inserts. But will take experimentation to find the sweet spot