fix: consistent label corpus across chains, ordered product entity list

[kasperpawlowski]

Summary

Fixes source inconsistencies that the euler-data-v3 unified labels importer currently has to resolve through a reviewed override manifest, and tightens verify.js so they cannot come back.

Data

• Entity descriptions: AlphaGrowth (59144), Clearstar (999), Hyperithm and K3 Capital (143) carried wording that drifted from every other chain file. They now use the same text as chain 1.
• Product entity list order: entity keeps its string-or-list form, but the list is now ordered. The first entity governs the product, any further entities are display-only co-brands with no governance role. kpk-securitize stays ["kpk", "securitize"] and reads as KPK-governed, Securitize co-branded. The v3 importer interprets it this way; no new field is introduced.
• Escrow vaults removed from products: four under Swaap Lend (Ethereum) and the Yieldpoint yUTY collateral vault under JPEG Trading x Yieldpoint (Base). Escrow vaults are the ones verified by the EscrowedCollateralPerspective; they are governor-less shared infrastructure and belong to no product. A scan of every escrow-verified vault on all eleven active chains (143 vaults) against every product and earn-vault list found exactly these five.
• Sonic (146): Re7's last active vault moves to deprecatedVaults, and both Sonic products get a deprecation reason, matching the other chains Euler no longer operates on.

Verification

verify.js now rejects:

• an entity whose name, logo, description, url or social differs between chain files;
• a product whose entity list is empty, repeats an entity, or references an unknown entity.

It cannot detect escrow vaults, since that needs on-chain perspective state; the v3 importer's database preflight blocks a product vault whose discovered type is escrow.

The README documents the ordering rule and the cross-chain profile rule.

Downstream

Consumers already read entity as string-or-array and take the first element as the owner, so nothing changes for them. The v3 importer follow-up (euler-data-v3#629) reads the rest of the list as co-brands. euler-data-v3#626 becomes unnecessary.

Test plan

• node verify.js passes on the branch
• Each new check verified to fail on a deliberately broken copy of the data (profile drift, duplicate entity, unknown entity, empty list)
• biome check . clean

[github-actions]

Hexagate sync — dry-run

chain	desired	hexagate	+adds	-removes	status
1	333	337	0	4	ok
56	105	105	0	0	ok
130	13	13	0	0	ok
143	81	81	0	0	ok
146	36	36	0	0	ok
239	22	0	0	0	skipped: chain not supported by Hexagate (not monitorable)
999	32	32	0	0	ok
1923	9	0	0	0	skipped: chain not supported by Hexagate (not monitorable)
8453	60	61	0	1	ok
9745	76	76	0	0	ok
42161	32	32	0	0	ok
43114	61	61	0	0	ok
59144	30	30	0	0	ok
60808	3	0	0	0	skipped: chain not supported by Hexagate (not monitorable)
80094	42	42	0	0	ok
total			0	5

chain 1: +0 / -4

Remove:

• 0x19756be2473a9c3351a426568ff9630c9d67f300
• 0x49aec2e6137615f0cf1cae334b5f3211953144be
• 0x57995a00ba1e3e17bcf08ba775bf225ca1f5f25e
• 0xd45a56f5b67eba836295b4c95fd6ea48d1334938

chain 8453: +0 / -1

Remove:

• 0xfa493128d7d092a082571b92334574a0a529e799

Skipped chains (no sync):

• 239 — chain not supported by Hexagate (not monitorable)
• 1923 — chain not supported by Hexagate (not monitorable)
• 60808 — chain not supported by Hexagate (not monitorable)

[Seranged]

Review of head c9836143ef72f8a0efd6d9ddb2690278f476486b against base edeaa7e0255c0daaf049048ddc2518e7b0f67d2d.

[P2] Compare social profiles independently of object key order — verify.js:470–472

JSON.stringify() makes the new cross-chain profile check sensitive to the insertion order of keys in social. Reversing only the social keys in 143/entities.json, without changing any values, makes node verify.js fail with entities: euler-dao.social differs between chain 1 and chain 143. These profiles are semantically identical. Please use deep equality or canonicalize object keys before comparing.

Downstream compatibility clarification: The claim that consumers already take only the first entity needs qualification. In the local Euler Lite checkout inspected during review, composables/useVaults.ts passes every product entity to governor verification via getDeclaredEntityKeys. First-entity curator display therefore does not establish display-only semantics for subsequent entities. Please distinguish the new importer convention from the existing governor-verification behavior and identify any required consumer follow-up.

Validation: the exact PR head passes node verify.js and Biome; GitHub verification and preview checks passed. In-memory negative cases confirmed rejection of profile drift, unknown entities, and empty entity lists. The key-order false positive above was reproduced. No repository files were changed.