fix(near): seed the omni-bridge assets, with origin-qualified symbols

[shahan-khatchadourian-anchorage]

Stacked on #432, which adds the seed table and the gap-fill rule this PR's entries interact with.

SEEDS covered no omni-bridge asset, so both ids carried by observed intent traffic fell to the unresolved arm:

Amount: 1000000000000 (unresolved nep141:eth.omft.near)
Amount: 2596756 (unresolved nep141:sol.omft.near)

Nothing on screen distinguished 1 ETH from 1 gwei. The three captured production payloads now read 0.000001 ETH, 0.000099 ETH, 0.002596756 SOL.

⚠️ Behavior change for integrators

Seeding an asset takes it out of reach of unattributable caller-supplied metadata. try_extract_from_chain_metadata accepts an entry it cannot attribute to a curator only as a gap-fill for an asset SEEDS does not cover. A wallet currently supplying token_mappings for any asset added here — unsigned, or signed by a key this deployment has not enrolled — will now have it refused instead of applied, by the gap-fill rule in try_extract_from_chain_metadata. The refusal is logged for the operator; #439, higher in the stack, also reports it to the signer as a rejected-token-metadata diagnostic.

This is the intended posture — a curated seed should beat data the parser cannot attribute, and such callers already get an unverified-token-metadata warning on every render — but it is visible to anyone integrating today. A signature from an enrolled curator still overrides normally.

Why the generator could not produce this

Neither bridge lookup is trustworthy on its own:

Lookup	Asks	Answers	Real intents carry
get_native_token_id	Eth	eth.bridge.near (legacy rainbow)	eth.omft.near
get_native_token_id	Base/Arb/Pol	*.omdep.near (deposit contracts)	*.omft.near
get_token_id	Ethereum USDC/USDT	*.factory.bridge.near (legacy)	eth-0x….omft.near
get_token_id	Base/Arbitrum USDC/USDT	nothing	—

The first row is how the wrong id reached the table originally.

So every entry's symbol and decimals is confirmed against the token contract's own ft_metadata, and every id rests on one of: observed traffic (eth.omft, sol.omft), a bridge-registry mapping (get_token_id resolves the canonical Solana USDC/USDT mints onto the two sol-* ids; get_native_token_id names nbtc.bridge.near for Btc), or a self-describing id embedding a source-chain address checkable directly.

Assets with none of those — the per-token Base and Arbitrum stablecoins — are deliberately left out rather than seeded from an unsourced id. They keep rendering as raw base units, which is honest about what the parser knows. The generator's input list matches, and says why.

Symbols are origin-qualified

ft_metadata symbols are not usable verbatim. Four distinct assets report {"symbol":"ETH","decimals":18} — ether via the omni bridge and via the legacy rainbow bridge, plus ether bridged from Base and Arbitrum — and four report {"symbol":"USDC","decimals":6}. AmountV2 carries only an amount and an abbreviation, so raw symbols would render Base ether identically to mainnet ether, and this swap identically to its mirror:

Send:    100 USDC.base        Send:    100 USDC.arb
Receive: 99.7 USDC.arb        Receive: 99.7 USDC.base

The bare symbol belongs to the asset native to its own chain; anything bridged from elsewhere carries an origin suffix. This extends the .e convention the first stablecoin seeds already used, and moves the legacy eth.bridge.near entry from ETH to ETH.e. every_seeded_symbol_is_unique enforces it, so a colliding entry fails the test rather than silently making two assets look alike.

This is the cheapest mitigation for the "asset id disappears once a token resolves" problem that lives entirely in the seed table — it does not need a schema change.

Notes

• BNB is omitted: bnb.omft.near serves no ft_metadata, and the deposit contract the bridge names instead is not an id intents carry.
• The ERC-191 fixture at verify.rs:213 uses base-0x8335….omft.near, one of the deliberately unseeded ids, so it still renders unresolved.
• All 15 entries were machine-checked against ft_metadata on mainnet: every decimals matches, every symbol matches or is the deliberate qualified form, and all ids are unique.

🤖 Generated with Claude Code

[prasanna-anchorage]

Verified the new SEEDS entries live against NEAR mainnet RPC — base.omft.near, arb.omft.near, and pol.omft.near all resolve to the exact symbol/decimals seeded (ETH/18, ETH/18, POL/18). Checked resolve()/is_seeded() callers for breakage on the new dotted symbols — none.

One non-blocking note: the origin-qualification suffix (.base/.arb/.sol/.e) is manually typed per SEEDS row, with only the every_seeded_symbol_is_unique test as a backstop against a future collision, rather than being derived structurally from the asset id's own chain segment. Not a bug in this PR, just worth a follow-up if the seed table keeps growing.

Approving.

[prasanna-anchorage]

Re-approving. My 2026-08-26 approval was dismissed by the stale-review rule when the stack was reordered, not by anything in this PR.

Re-checked head 3ae5afac rather than assuming: the seed table is byte-for-byte what I verified live against NEAR mainnet RPC — base.omft.near -> ETH.base/18, arb.omft.near -> ETH.arb/18, pol.omft.near -> POL/18, alongside eth.omft.near ETH/18, sol.omft.near SOL/9, btc.omft.near BTC/8, nbtc.bridge.near NBTC/8 and eth.bridge.near ETH.e/18. every_seeded_symbol_is_unique is still the backstop. The only change since is the rebase that moved this PR to sit directly on near-d-token-metadata.

The maintainability note from last time stands and is tracked as #469 (manual origin-suffix per row plus a drift check against omni.bridge.near); nothing blocking here.