Saved query conflict token: non-serializer writers do not advance query_revision

Problem

DataWarehouseSavedQuery.query_revision is the optimistic-concurrency token the saved-query API hands to clients as latest_history_id. Clients send it back as edited_history_id on the next query write, and the write is refused when it no longer matches the row.

Only the saved-query serializer advances that revision. Other code paths rewrite a saved query's SQL directly and leave the revision alone:

• products/endpoints/backend/logic/materialization.py — prepare_executable_query() rebuilds the executable HogQL before each materialization run and saves query and updated_at only.
• products/endpoints/backend/logic/materialization.py — _configure_saved_query() points the saved query at a version's materializable HogQL.

A token read before either rewrite still passes the conflict check afterwards, so the next API write overwrites SQL the caller never saw.

Scope

This predates the revision column. The same gap existed when the token was derived from the activity log, because neither path writes an activity row for the query change. Raised as a non-blocking follow-up during review of #102183.

What to decide

Bumping query_revision from the endpoints materialization path closes it, but it is a behaviour change for endpoint owners: a SQL editor tab opened before a Temporal rebuild would start failing its next save with "The query was modified by someone else." Worth deciding whether that refusal is wanted, or whether endpoint-backed saved queries should be excluded from the conflict protocol instead.