fix(instance): align persisted state labels across admin and dashboard - #7889

Review: label alignment for persisted instance states

The core of this change is correct, and I verified each claim against the code rather than the description:

• InstanceStatusEnum still pins 0=DELETED, 1=ONLINE, 2=OFFLINE, and values().length == 3, so no new persisted code is introduced and historical rows stay valid.
• The only production caller of getNameByCode is InstanceCheckService#getInstanceDataVisual: line data passes the literal 0/1/2, and pie data passes arbitrary codes. So changing the fallback from DELETED.name to UNKNOWN cannot affect the timeout/recovery transitions in doCheck(), which compare against getCode() only.
• Schema comments, the five dialect upgrade scripts, the H2 schema and the new contract doc all agree on the same code table.
• The frontend change is a clean bundle swap (index.16dee401.js deleted, index.72158727.js added, index.html reference updated) with provenance recorded.

A note on the upgrade scripts: db/upgrade/2.7.2-upgrade-2.7.3-*.sql was introduced two days ago by #7673 and master is still 2.7.2-SNAPSHOT, so editing those files in place is fine here — nobody has consumed them from a release yet. MODIFY COLUMN / COMMENT ON COLUMN are both idempotent, and the definition repeats the existing type and NOT NULL with no default, so re-running is harmless.

Non-blocking comments

1. Pie data can emit duplicate UNKNOWN slices. getInstanceDataVisual groups by state code first, then maps each code to a name, so two distinct unrecognized codes (e.g. 3 and 99) produce two separate entries that both render as UNKNOWN. If the contract is "unknown is a presentation fallback, not a state", group by the mapped name instead:

   Map<String, Long> pieData = instanceInfoVOS.stream()
           .filter(instance -> Objects.nonNull(instance.getInstanceState()))
           .collect(Collectors.groupingBy(vo -> InstanceStatusEnum.getNameByCode(vo.getInstanceState()),
                   Collectors.counting()));

   The new test only exercises a single unknown code, so this case is not covered today.

2. "UNKNOWN" is a magic string in a shared enum. shenyu-common is consumed outside Admin, and the dashboard contract now depends on this exact literal. Consider exposing it as a documented constant (e.g. public static final String UNKNOWN_STATE_NAME = "UNKNOWN") so the doc, the enum and InstanceStatusEnumTest cannot drift apart. Keeping it out of the enum constants is the right call — a real constant would collide with the persisted-code space — but that rationale is worth a line in the Javadoc.

3. Compatibility note for downstream consumers. getNameByCode previously never returned a value outside the enum; after this change it can return UNKNOWN. Anything downstream that switches on the returned string (or assumes it is a known state name) will now see a new value. The contract doc covers the semantics, but it deserves a line in the release notes too, since this is a public API in shenyu-common.

4. Nit: testExpiryAndRecoveryKeepPersistedStateCodes mutates instanceHeartBeatTimeOut / deleteTimeout via ReflectionTestUtils. That is safe here because the class builds a fresh InstanceCheckService per test with MockitoExtension (no shared Spring context), but if this test class ever moves to @SpringBootTest those fields will leak into sibling tests.

LGTM apart from the above. The docs/instance-state-contract.md write-up is a good addition — it makes the retained-expired-record semantics explicit, which is exactly what was missing when the dashboard labeled 0 as unknown.

Re-approving after the master merge. The change only corrects the persisted state labels to match InstanceStatusEnum (0 = DELETED), and keeps every stored numeric value and transition untouched. The upgrade scripts only rewrite the column comment, so no data migration is required. The contract document makes the DELETED-vs-unknown distinction explicit, which is what the dashboard mismatch needed.

One coordination note: this PR also rebuilds the bundled dashboard artifacts, which overlaps the scope of #8003. Whichever lands first, please make sure the second one is dropped or rebased so the static bundle is not replaced twice.