search: query_fallback_digest changes across semantic activation because the exact profile's evaluation_result_anchor flips authorities

[ScriptedAlchemy]

Surfaced by the #1097 lane in semantic_availability_journey_test::retrieval_answers_before_activation_and_is_unchanged_by_live_semantic_activation (phase 3, activation must preserve the canonical core query bytes, semantic_availability_journey_test.rs:571), which now runs through activation with the FastEmbed fixture and fails only here.

Measured with a temporary scaffold: before and after activation the serving exact query profile is byte-identical (profile.query-fallback, same calibrations / weights / budget, same key) except evaluation_result_anchor:

• before activation: policy.query-fallback.workload.v1.sha256:a4c7… — the checked-in core policy mounted at project open by 46f3ddc ("preserve core search without fake activation", prepare_core_query_authority_on_project_open);
• after activation: search-eval:sha256:c23e… — the configuration store's evaluated initial fallback, promoted into serving by prepare_after_successful_activation → resolved_query_profile → rollback slot.

The anchor is written into every exact-tier RankingDecision.policy_anchor (fusion.rs:988), which is part of QueryFallbackSubpayload's digest input, so the public query_fallback_digest moves while candidates, order and lane contributions are identical (verified from dumped payloads). Both sides are deliberate.

Decision needed (owner): should query_fallback_digest be invariant across semantic activation?

1. Yes — then either unify the two exact-profile authorities so one anchor serves before and after (the checked-in policy anchor is provenance for the same evaluated fallback), or exclude provenance (policy_anchor) from the digest domain so the digest names the ranking bytes only; or
2. No — the journey's claim is too strong and should assert candidate/order equality plus an explicitly changed anchor.

Consumers that key caches or comparisons on query_fallback_digest (search-eval report pins, WORKLOAD_SHA256, any dashboard drift view) decide which. The assertion is left in place, not weakened, until this is decided.