fix(preprocess): start the first preprocess run instead of crashing on 404

[aural-psynapse]

Why

run_preprocess() turns a freshly-ingested intercept table into the preprocessed form its collection needs before any query can run or be proven. It checks the current preprocess status first and only then starts a run.

The problem: a table that has never been preprocessed has no status record yet, so the status endpoint returns 404. That 404 raised straight out of the initial status check and crashed run_preprocess() before it ever called start_preprocess() — so the very first preprocess never happened.

Consequence: the collection stayed is_valid: false (invalid_reason: table_not_preprocessed), and every proof query against it failed — evaluate_handoff() returned ERROR with an empty per_claim. On a fresh setup, verification could never succeed.

Changes

• In run_preprocess(), treat a 404 from the initial status check as "not started" and proceed to start the first preprocess run. Any non-404 error still propagates unchanged.

Verification

Reproduced against the live backend: on a never-preprocessed table, row-returning queries returned 500 while COUNT(*) succeeded, and the collection reported table_not_preprocessed. Running start_preprocess first flipped the collection to is_valid: true and the same row query resolved. With the fix, a full end-to-end run reaches PASS on an honest claim and CAUGHT on a tampered one.