near: scheduled drift check for the compiled-in token SEEDS table, + structural origin-suffix derivation

[prasanna-anchorage]

Follow-up from #463 review.

Problem

src/chain_parsers/visualsign-near/src/presets/intents/tokens.rs's SEEDS table is a hand-maintained snapshot, populated by running scripts/gen_near_token_seeds.sh (added in #432) once and pasting the output in by hand. Two gaps follow from that:

1. No drift detection. Nothing re-checks that an already-seeded id's on-chain ft_metadata still matches what's compiled in. decimals is load-bearing — resolve()'s doc comment already says a wrong value "silently misrenders amounts" — so if a bridged token's metadata ever changed on-chain, there is currently no signal at all, let alone before a signer sees a wrong amount.
2. Manual, test-caught-only origin-suffix collisions. The origin-qualification suffix (.base, .arb, .sol, .e) is typed by hand per row (see the module doc comment: "Symbols are origin-qualified, and unique"), with only every_seeded_symbol_is_unique as a backstop. That test only fires if someone remembers to run it after copy-pasting a new on-chain ft_metadata symbol.

Proposal

A) Structural suffix derivation (no new job needed, can land any time after #463). Every SEEDS id already encodes its origin chain in its own shape (<chain>[-<addr>].omft.near, or .factory.bridge.near/.bridge.near for the legacy rainbow-bridge entries). Derive the suffix from the id's own prefix instead of hand-typing it, so a colliding bare symbol becomes structurally impossible rather than something a test happens to catch.

B) A scheduled drift-check job (new — this repo has no schedule:-triggered workflow yet). A weekly GH Actions workflow that:

1. Runs gen_near_token_seeds.sh against mainnet RPC, extended to also re-verify ft_metadata for every id already in SEEDS (not just resolve the generator's own input list).
2. Diffs the result against the current SEEDS table.
3. On any diff, opens/updates a single tracking issue summarizing what changed — decimals/symbol mismatch on an existing entry, or a newly-resolvable token not yet seeded.
4. Does not auto-commit or open a PR. The script's own doc comment is explicit that the bridge registry returns legacy/unused ids and misses Base/Arbitrum's per-token assets entirely (tokens.rs's "Sourcing" section), so reconciling against observed production traffic still needs a human; automating past that point risks silently seeding a wrong or dead id.

Depends on

• feat(near): add signed token-metadata support for NEAR Intents #432 (adds scripts/gen_near_token_seeds.sh)
• fix(near): seed the omni-bridge assets, with origin-qualified symbols #463 (adds the origin-qualified SEEDS entries and the uniqueness test this replaces the safety net for)