feat(ui): warn when SPA-vs-backend major version drifts

[cnewkirk]

Summary

On SPA boot, fetches /opennms/rest/info and compares the backend's major version against a UI_COMPATIBLE_API constant baked into the build. If they don't match, renders a fixed yellow banner at the bottom of the screen with a dismiss button. Does not block use — just informs the user that the UI was built for a different OpenNMS major and some features may not work correctly.

What changes

• ui/src/main/main.ts: top-level await checkApiCompatibility() runs once at boot; the resulting message (or null) is provided via Vue's inject API.
• ui/src/main/App.vue: injects the value, wraps it in a ref so the dismiss button can clear it, renders the banner when set.
• Banner background uses var(--p-yellow-500, #eab308) — picks up PrimeVue's theme color when available, falls back to a hardcoded yellow otherwise.

Why ship this with versioning

A versioned UI (#6) makes it possible to install a SPA built for OpenNMS 35.x onto a 36.x backend. That's a useful escape valve, but users need a visible signal that they're in that state. This banner is the cheapest possible signal — pure client-side, no backend changes, dismissible.

Test plan

• yarn build succeeds against develop
• Manual: serve the SPA against a matching backend — no banner. Modify UI_COMPATIBLE_API to '34', rebuild, reload — banner appears with version-mismatch message; dismiss button hides it
• Manual: ensure dismissal does not persist across reloads (banner re-checks on each boot — by design)

Relationship to other PRs in this series

• Independent of feat(ui): add org.opennms.web.ui opt-in for next-generation UI #5 (opt-in gate)
• Independent of feat(ui): pluggable UI versioning via servlet filter (cross-platform) #6 (cross-platform versioning) — though most useful when paired with feat(ui): pluggable UI versioning via servlet filter (cross-platform) #6, since that's what makes UI/backend version drift a routine occurrence rather than an upgrade-only edge case