fix(plugin-devkit): reject package-relative theme assets at check time

[VMF-HIBIKI]

Summary

pi-plugin check now fails contributes.themes[].assets entries that the host-core installer rejects, with a message that names the migration path. Fixes #943 (direction A, author-time half).

Problem

ADR 0255 made theme assets absolute filesystem paths and the host-core installer enforces it. The SDK validator (isThemeAssetPath), the SDK doc comments ("may be package-relative or absolute"), and the PluginThemeContrib.assets doc still accept the package-relative spelling, so a theme plugin can pass pi-plugin check, publish to a catalog, and then fail installation for every user with an error that reads like a plugin bug:

PLUGIN_INVALID: theme cyber-diva asset themes/assets/wallpaper-dark.webp must be an absolute image or font path

An absolute spelling is not an escape hatch for a distributed package either: the installer requires the referenced file to already exist on the installing machine (asset missing), so package-shipped bytes have no installable manifest spelling at all (see #943 for the full matrix).

Impact

• Catalog theme plugins that follow the SDK documentation are uninstallable for every user (case: local.miku-theme 1.0.0 in AIUO-Net/pi-desktop-plugins, review-approved, pi-plugin check-clean).
• The failure surfaces at install time on end-user machines, far from the author, with no migration hint.

Change

packages/plugin-devkit/src/check.ts gains one check after validateManifest: for every contributes.themes[].assets entry whose normalized form is valid but not external (normalizeThemeAssetPath + isExternalThemeAssetPath, both already exported by the SDK), it reports theme.asset-package-relative with the ADR 0255 rule and the two migration routes (bytes in pi.plugin.getDataPath() referenced by absolute path, or runtime registration via pi.themes.upsert).

Deliberately scoped:

• The shared SDK normalizer, the runtime loader, and the existing SDK tests are untouched — installed plugins keep resolving package-relative assets exactly as today. Aligning those with ADR 0255 is a breaking change whose scheduling belongs to the maintainers (open question in [Bug] Theme plugins with package-relative assets pass pi-plugin check but cannot be installed (SDK/loader vs installer disagree after ADR 0255) #943).
• No devkit-side copy of the extension whitelist: the check reuses the SDK's own path semantics, so it cannot drift from what the host normalizes.

Affected ADRs / specs

• Implements the author-time half of ADR 0255 (docs/adr/0255-theme-assets-by-absolute-path.md), which already states that normalizeThemeAssetPath (SDK) rejects package-relative references.
• No ADR change of its own; loader enforcement and SDK doc alignment are left to [Bug] Theme plugins with package-relative assets pass pi-plugin check but cannot be installed (SDK/loader vs installer disagree after ADR 0255) #943.

Validation

pnpm --filter @pi-desktop/plugin-devkit test        → 49 passed (49), incl. the new case
pnpm --filter @pi-desktop/plugin-devkit typecheck   → clean
node scripts/check-pr-base-main.mjs                 → PR base check passed: head a634b687706c is the base

New test fails theme assets the installer rejects: package-relative paths (ADR 0255) covers: package-relative asset → error quoting the asset, the absolute-path rule, and pi.themes.upsert; absolute spelling → check stays green.

E2E: NOT RUN — this change is confined to the devkit CLI's static checks (pi-plugin check) and has no runtime surface in the desktop app; unit coverage exercises both outcomes directly. Remaining risk is limited to the wording of the new diagnostic.

Compatibility / migration

• Authors with package-relative assets now get a hard error from pi-plugin check before publishing; the message states where the bytes must live. That is the intended ADR 0255 behavior arriving at author time instead of at users' install time.
• Already-published packages and locally installed plugins are unaffected by this PR.