fix(tip403): resolve policyIdCounter from L1 instead of cache

[CrytoInsight]

fix(tip403): resolve policyIdCounter from L1 instead of cache

Description

The TIP-403 proxy precompile is meant to be a faithful in-zone mirror of the L1
registry: when a contract running inside the zone calls a read method, the proxy
answers with what L1 would say. Almost every read honors that contract — on a
cache miss it falls back to an L1 RPC call. policyIdCounter() was the
exception.

Instead of asking L1, PolicyProvider::policy_id_counter derived its answer
from the cache, returning max(observed policy id) + 1. The problem is that the
cache only contains policies the zone has actually seen events for. Any policy
that was created before the subscriber came online, or that no tracked token
ever referenced, simply isn't there. So the highest cached id is only a lower
bound on the real counter, and the proxy could confidently hand back a value
below L1's authoritative policyIdCounter — a silent disagreement with L1 that
nothing else in the proxy exhibits.

The fix brings this read in line with the rest of the proxy. It now queries the
registry's policyIdCounter() on L1, pinned to last_l1_block so the answer is
deterministic and identical across nodes (the same anchoring the other reads
already use). The cache-derived lower bound survives only as a fallback for when
the RPC itself fails. Mechanically it follows the existing policy_exists_sync
shape: block_in_place + block_on around the call.

I added two tests next to the provider: one feeds a mocked L1 response and
checks the authoritative value is returned; the other leaves the mock empty so
the RPC errors, and checks we fall back to the cache-derived bound. Both pass,
alongside clean clippy and fmt runs.