First part of integrating the enhancements explored at
aztec-labs-eng/oxide#257

Closes F-808

(cherry picked from commit 8a3f7e6)

Some stores were being accessed without checking if the associated
accounts were in scope or not. For logs I added this to the service, but
we're not yet consistent in how we use services (call-lived, tx-lived?)
so in other cases it is just inlined in the oracle.

(cherry picked from commit ce12e29)

Additions to the README on gas and fees

(cherry picked from commit 4d53a9f)

…evidence (#24655)

Fixes the sender tag sync conflict from
https://gist.github.com/nventuro/0aa690736b1d2865e27197723a814e9d,
including the "Window straddle" residual edge.

Discovery could re-derive a different index range for an already tracked
(secret, txHash) pair and hit the `Conflicting range` throw in
`storePendingIndexes`, permanently wedging the secret. Two triggers:

- A same-PXE tx partially reverts: the chain only shows the surviving
non-revertible sub-range of the prove-time entry, and the throw fired
before the finalized receipt step could resolve it.
- A tx straddles a sync window boundary: the window loop assembles its
range piecewise, so window 2 stores a different range than window 1
(latent regardless of reverts).

Fix: discovery passes `mergeExisting` to `storePendingIndexes`, which
widens the stored entry to the union of both ranges (grow-only, driven
by onchain evidence). The finalized receipt step still resolves partial
reverts. The only other writer of pending ranges,
`persistSenderTaggingIndexRangesForTx` (records the indexes a tx sent
from this PXE used, at prove time), does not pass the flag and still
throws on a mismatch: there it indicates a bug, not partial onchain
evidence.

Red-green (all fail on the base with the `Conflicting range` throw):
- partial revert repro: finalizes the surviving index, frees the
squashed ones, repeat sync is a no-op
- cross-sync widen: an entry tracked from an earlier sync grows when
discovery evidences further indexes
- window straddle: drives the actual window advance loop, asserts per
window queried tags and that the widened entry later finalizes cleanly

Store-level tests pin the union semantics: a sub-range keeps the entry,
a range beyond it widens it, an untracked tx still stores.

(cherry picked from commit fd7515d)

This fixes a scoping bug where an account's ivsk would be used to
produce an ECDH shared secret even if that account was not in scope. The
base wallet class was adjusted to put these in scope when an explicit
sender is selected for tagged messages.

(cherry picked from commit 4994006)

Fixes F-700
Fixes F-765

- makes TXE tagging secret strategy resolution mode-aware, matching
PXE's resolveTaggingSecretStrategy hook request
- supports configuring unconstrained and constrained delivery strategies
independently in Noir tests
- falls back to PXE's default strategy for unset modes, while preserving
the no-hook path when no strategy is configured
- adds coverage for resolved tagging strategy
serialization/deserialization and per-mode TXE defaults
- updates execution hook docs for the new Noir test helpers

(cherry picked from commit 6dd1271)

)

Fixes
[F-680](https://linear.app/aztec-labs/issue/F-680/migrate-pxe-tagging-stores-to-prefixed-apptaggingsecret-keys)

Migrates PXE tagging-store keys off the legacy two-part
`AppTaggingSecret` string format (`secret:app`) so every persisted key
uses the uniform self-describing `kind:secret:app` form.

- `AppTaggingSecret.toString()` now always emits `kind:secret:app` (the
unconstrained special case that emitted the legacy two-part key is
gone).
- `AppTaggingSecret.fromString()` only accepts the three-part form; a
two-part legacy key now throws instead of parsing.
- Bumped `PXE_DATA_SCHEMA_VERSION` 12 → 13.

Since the general PXE migration framework does not exist, and per the
issue discussion, this cuts over via the schema-version bump rather than
a dual-read / self-healing path.

`initStoreForRollupAndSchemaVersion` wipes any DB whose stored schema
version differs from the current one on open, so a DB written with
legacy keys is cleared before the new parser ever reads it.

**Blast radius:** the wipe resets the *entire* PXE DB (addresses, notes,
contracts, key store, L2 tips, facts, and tagging), not just tagging
data, because they share one backing KV store. Existing wallets re-sync
from genesis after upgrade. This is inherent to any
`PXE_DATA_SCHEMA_VERSION` bump.

- `app_tagging_secret.test.ts`: pins the new three-part unconstrained
`toString()`, adds a "rejects the legacy two-part format" case, drops
the now-redundant kind-prefixed-unconstrained test.
- `pxe_db_compatibility.test.ts`: adds a pre-migration wipe test that
writes a raw legacy two-part key at schema v12, reopens at v13, and
asserts the raw map is empty (it asserts raw map contents rather than a
high-level getter, which would false-pass since a new three-part
`toString()` never reconstructs a legacy key).

(cherry picked from commit 736f391)

Adds an oracle to check whether a collection of block hashes is present
in the archiver tree as of a given block. An upstream port of:
aztec-labs-eng/oxide#257

Note: I considered making this batch call return something more
"interesting" than existence booleans (such as MembershipWitnesses), but
that would potentially be heavy over the wire and there's no current
evidence of it being needed. We can add a new oracle for that if turns
out to be useful in the future.

Closes F-810

(cherry picked from commit 2967179)

Adds a new `getTxEffects` oracle to fetch tx effects in batch.

(cherry picked from commit 7a77232)

(cherry picked from commit 97b4c75)

…ping labels (#24752)

(cherry picked from commit d2db074)