Support for validFrom app-data field

[AryanGodara]

Description

Add validFrom (app-data, unix seconds). An order enters the batch auction only once now >= validFrom. NULL/absent = eligible immediately (unchanged for existing orders). Groundwork for fast-path.

Changes

• Nullable orders.valid_from column (V115) + partial index (V116), no backfill.
• Gated in the solvable-orders SQL code.
• Onchain orders backfill valid_from from app-data inside insert_order_hooks (reusing the fetch it already does).
• Rejects validFrom >= validTo; a past validFrom is fine.

Testing

• DB: full-build gating + both incremental branches + on-chain backfill.
• Unit: validFrom >= validTo rejection.
• e2e: a regular EIP-712 order and an on-chain ethflow order are both held out of the auction until validFrom, then settle.

Note:

Overlaps #4668, compared the two, fixed e2e tests accordingly, and removed some redundant unit tests, and focused the PR

[github-actions]

Reminder: Please update the DB Readme and comment whether migrations are reversible (include rollback scripts if applicable).

• If creating new tables, update the tables list.
• When adding a new index, consider using CREATE INDEX CONCURRENTLY for tables involved in the critical execution path.
• For breaking changes, remember that during rollout k8s starts the new autopilot, runs the Flyway migration, and only then shuts down the old pod. That overlap means the previous version can still be processing requests on the migrated schema, so make it compatible first and ship the breaking DB change in the following release.

---

Caused by:

• database/sql/V115__add_valid_from_for_orders.sql
• database/sql/V116__create_valid_from_index.sql

[github-actions]

Reminder: Please consider backward compatibility when modifying the API specification.
If breaking changes are unavoidable, ensure:

• You explicitly pointed out breaking changes.
• You communicate the changes to affected teams (at least Frontend team and SAFE team).
• You provide proper versioning and migration mechanisms.

---

Caused by:

• crates/orderbook/openapi.yml

[claude]

Claude finished @AryanGodara's task in 5m 0s —— View job

---

PR Review: Support for validFrom app-data field

I reviewed the full diff against origin/main. Overall this is a clean, well-tested change — the gating logic is correct and the tricky "pending→valid is not a DB write" incremental case is handled properly.

Things I verified as correct (no action needed):

• No gaps in the incremental refresh. Branch 2 of open_orders_by_time_or_uids re-selects valid_from ∈ (after_timestamp, now], and solvable_orders.rs:447 pushes the checkpoint back 60s each cycle, giving a generous overlap so a validFrom crossing is never missed. On restart the cache is empty and the fully-gated all_solvable_orders path runs, so no gap there either.
• INSERT bind sequence ($21=true_valid_to, $22=valid_from) matches the column list — 22 columns, 22 binds.
• jit_orders SELECT correctly adds NULL AS valid_from to stay aligned with FullOrder (by-name FromRow).
• Backfill ordering — insert_order_hooks mutates orders before insert_orders_and_ignore_conflicts, so the backfilled value is persisted.
• Backward compat — nullable column + partial index, no backfill, skip_serializing_if on the new API field. CREATE INDEX CONCURRENTLY follows existing repo precedent (V102/V112).

Two findings posted inline:

1. onchain_order_events/mod.rs — the valid_from backfill is an implicit, name-hidden side effect of insert_order_hooks with an invisible ordering dependency on the subsequent insert. Suggest extracting it or documenting the dependency.
2. order_validation.rs — the validFrom >= validTo guard only covers API orders; on-chain/ethflow orders bypass it and would be silently held out until expiry. Worth a deliberate decision + comment.

Neither is blocking. Nice work on the test coverage (DB gating + both incremental branches + on-chain backfill + e2e for both order types).

[MartinquaXD]

Also I'm a bit hesitant about the runtime of the new query. We are already adding an index for the new column but we should probably do a test run on the prod DB before merging this PR.

[MartinquaXD]

Actually after thinking more about it it's not clear to me why we even split block based change detection from time based change detection. It seems like that could become 1 giant DB query. That way we save on roundtrips and possible help the query planner optimize better. 🤔
This would mean quite a change so it's out of scope for this PR.