feat: show one bundled FTW version when packaged as the Home Assistant add-on

[HuggeK]

What

When Core runs inside a single-image bundle that sets FTW_BUNDLE=home_assistant_addon (the Home Assistant add-on), Settings → System now shows one bundled FTW version row instead of the per-container Core/Optimizer breakdown, and the Optimizer Update/Rollback buttons are not rendered there. Native installs are unchanged.

• go/internal/components/bundle.go: new Bundle type + BundleFromEnv() reading FTW_BUNDLE / FTW_BUNDLE_VERSION.
• /api/components includes a bundle object when set; omitted for native installs.
• web/settings/tabs/system.js: new pure bundleDisplay() helper picks the collapsed view; drivers row, optimizer fallback warning, and the component-action status line stay.

Why

In the Home Assistant add-on, Core and the Optimizer ship in one image whose updates and rollback belong to Supervisor (srcfl/home-assistant-addons, self-update disabled). A per-container version breakdown with update buttons misleads there: nothing updates independently, and the operator's real question is "which FTW version is this add-on running?"

Behaviour details and safety notes

• The optimizer degraded/fallback warning is still shown in bundled mode — it is a health signal, not a version breakdown.
• The Drivers row and Refresh stay: signed managed drivers remain independently updateable in the add-on.
• Button wiring is unchanged; the existing if (btn) guards already tolerate the buttons being absent from the DOM.
• bundle.version (the add-on version) is optional; the FTW version shown is Core's compiled-in version.
• Unknown FTW_BUNDLE kinds keep the native view, so nothing changes until a packaging opts in.

Testing

• go test ./internal/components/ ./internal/api/ — new tests: TestBundleFromEnv*, TestComponentsReportsBundlePackaging, TestComponentsOmitsBundleForNativeInstalls (pre-existing failures in internal/api on Windows — backup lifecycle + myUplink OAuth — fail identically on the untouched base).
• node --test web/settings/tabs/system.test.mjs — 6/6 pass, including three new bundleDisplay cases.
• node --test web/javascript-syntax.test.mjs — pass.
• gofmt/go vet clean for the touched packages (two pre-existing gofmt offsides in api.go/api_components.go left as-is to keep the diff small).

Companion add-on change: HuggeK/home-assistant-addons sets FTW_BUNDLE / FTW_BUNDLE_VERSION in the add-on image; it is a no-op until an FTW release containing this PR is pinned there.

🤖 Generated with Claude Code

[frahlg]

Read the whole diff. Clean and well-scoped, and it keeps the part that matters: the degraded-optimizer warning still renders in the bundled branch even though the Optimizer row is gone. Collapsing the row without keeping the warning would have hidden a real fault behind a packaging decision, and it does not.

Checked and liked:

• bundleDisplay() is pure, exported through _pure, and covered on both sides — native install returns null, and an unrecognised bundle.kind also returns null, so a future bundle kind cannot silently collapse the UI.
• BundleFromEnv() returns nil for an unset FTW_BUNDLE even when FTW_BUNDLE_VERSION is set, which is the right precedence and is pinned by a test.
• /api/components omits bundle entirely for native installs rather than emitting an empty object, and there is a test asserting the key is absent.

One small thing, not blocking: bundleDisplay gates on the literal "home_assistant_addon" while the Bundle type is generic over Kind. That is the conservative choice today, but the next bundle kind will need this branch touched as well as the packaging. Worth a comment at the gate saying so, so the next person does not assume the UI is already generic.

@erikarenhill owns web/, so web/settings/tabs/system.js is his call. The Go side reads correctly to me.