fix: skip reservation injection when preOps has an outer DECLARE

[steps-re]

Summary

Reservation injection produces invalid BigQuery SQL for any model whose preOps starts with a DECLARE, and this is currently breaking the CI test matrix on every PR.

Details

The package injects SET @@reservation='...'; into an action's pre-operations at publish() time. When a model supplies its own preOps via a chained call — publish(...).preOps('DECLARE ...').query(...) — the reservation statement lands before the user's DECLARE, compiling to ["SET @@reservation=...", "DECLARE ..."]. BigQuery rejects this because a DECLARE must be the first statement in a script, so the model fails to run.

This is exactly the failure making the CI matrix (Dataform 2.4.2 / 3.0.48) red on every PR — e.g. Table test_incremental should NOT have a reservation injected, but found one in preOps. CI only runs on pull_request, so main never exercises the matrix and it went unnoticed.

Fix

Monkeypatch the builder's .preOps() (mirroring the existing .queries() patch) so a later-supplied outer DECLARE removes the reservation statement we injected. Handles both Dataform v3 (proto.preOps) and v2 (contextablePreOps).

Verification

• Reproduced on main: ./scripts/test-matrix.sh fails at 2.4.2 with the test_incremental DECLARE error; confirmed identical string in the repo's own CI logs.
• After fix: npx jest → 89/89 pass; ./scripts/test-matrix.sh → SUCCESS for both 2.4.2 and 3.0.48. Normal reservation tables/views/operations still get their reservation injected; only DECLARE-carrying models are skipped. eslint exit 0.

This turns the PR CI matrix green (and unblocks the pending dependency PRs). Worth noting CI runs only on pull_request, which is why main hid the regression.

[max-ostapenko]

@steps-re Thanks for raising this!

Though it would be a safer approach to avoid injecting the reservation in the first place, keeping it completely clean without having to "delete" or strip anything from the SQL.

It would be a direct equivalent to how action.queries handles operations. Since every valid table/view builder has both a .preOps() and a .query() method, we can intercept both at creation time.

Could you adjust this?

[max-ostapenko]

Let's avoid injecting the reservation in the first place.

[steps-re]

Thanks @max-ostapenko, that's cleaner. Reworked to avoid injecting the reservation in the first place instead of stripping it back out.

It now mirrors the operations .queries() patch: I intercept the builder's .preOps() and .query() and inject the reservation only when there's no outer DECLARE. Concretely:

• .preOps() with no DECLARE → prepend the reservation to the user's preOps.
• .preOps('DECLARE ...') → passed through untouched, reservation never added.
• .query() with no preOps at all → reservation injected then (no DECLARE possible).

Nothing gets deleted after the fact. The compiled-object / already-resolved paths are unchanged and still use direct injection. jest is 89/89 and the 2.4.2 / 3.0.48 matrix (including the DECLARE-skip check) is green. Ready for another look.