build: follow Core and Optimizer onto the trixie base

[HuggeK]

Follows Core and the Optimizer onto the Debian 13 "trixie" base, and documents
what .local device names actually depend on here.

srcfl/ftw#731 has merged, so Core, the
updater and the Optimizer now all derive from one trixie base upstream. This
repo builds the app FROM ${FTW_OPTIMIZER_FROM}, so its runtime layer lands on
that base too — the fixtures have to follow or CI stops testing what ships.

What changes

• tests/fixtures/optimizer/Dockerfile → python:3.14-slim-trixie. This is the
  one that matters: the app's own apt-get layer is built on top of it, so the
  fixture has to match the suite the real install runs against.
• tests/fixtures/core/Dockerfile → same, for consistency. Core contributes
  only three copied paths, so its base has no runtime effect here.
• ftw/Dockerfile — comments only. Records where the suite comes from, and why
  libnss-mdns is deliberately absent.
• ftw/DOCS.md — a new section on devices named zap.local.

Verified, not assumed

CI builds the app's runtime layer on the fixture, so a green run here is real
evidence for the base bump: apt-get install --no-install-recommends ca-certificates tini tzdata resolves on trixie, and tini still lands at
/usr/bin/tini, which the ENTRYPOINT hard-codes as a literal path. smoke.sh
then exercises the health check and the optimizer kill/restart cycle on that
image.

The packages stay unpinned, as the comment above them already explains: Debian
does not keep old revisions in its normal index, so pinning would break later
rebuilds without buying a stronger guarantee.

The docs section was wrong, and a pilot install said so

The first version of ftw/DOCS.md here claimed FTW resolves .local itself and
does not use the operating system's resolver. Testing on a pilot HA green
disproved it. Probing one device three ways through POST /api/drivers/test:

Host	Result
its configured IP address	connect: no route to host
zap.local	reached the device — returned its serial and a full discovery
a nonexistent .local name	lookup … on 172.30.32.3:53: no such host

172.30.32.3 is Supervisor's own DNS service, which ships an
mdns plugin
backed by systemd-resolved. So .local already resolves here, over ordinary
unicast DNS, on the published v1.10.0-beta.1 — and it works under
host_network: true, which was the part that could not be settled from source.

Why the avahi paragraph still stands, for a different reason

Supervisor's map vocabulary is a fixed enum (data, config, ssl,
local_apps, backup, share, media, homeassistant_config,
all_app_configs, app_config), so an app cannot bind /run/avahi-daemon.

But there is also nothing there to bind. HA OS runs no avahi at all — the
multicast plugin is
mdns-repeater, a packet
relay with no query API.

The section now says what the feature depends on and, more usefully, what a user
could get wrong: systemd-resolved on the host. HA OS always has it; a
Supervised install has it if it followed the documented setup, whose first step
converts the host to NetworkManager and systemd-resolved. A host that skipped
that resolves no .local names and must use IP addresses.

It also states plainly that there is no plugin to install. Supervisor hard-codes
its five built-in services and starts them itself; they are not add-ons, cannot
be installed or removed, and an app cannot declare a dependency on one.

Not in scope

compatibility.yaml still pins the digests of the last published beta, which
predates the base move. Re-pointing it needs a release published from current
upstream master, which is the beta workflow's job rather than this PR's.

srcfl/ftw#788 has since merged. This
head now uses python:3.14-slim-trixie for the Optimizer fixture, matching the
current upstream image.

[miravoss26]

Reviewed. Adds a DOCS.md section explaining .local name resolution on HA (Supervisor's own DNS → systemd-resolved), and bumps the Dockerfile bases (Core/Optimizer fixtures + FTW itself) from python:3.12-slim-bookworm to -trixie, matching srcfl/ftw#731.

• Docs: clear, specific, cites the actual failure string (no such host vs a resolver-address mismatch) — useful for whoever hits this next.
• Dockerfile comment on libnss-mdns explains why it's omitted rather than just omitting it — good, since a future reader would otherwise "helpfully" add it back.
• All 5 checks green (repo/shell lint, HA app lint, amd64 + aarch64 build+smoke).
• No secrets, no new network destinations, no dependency changes beyond the base image tag.

Safe to merge from my read.

[frahlg]

Final pass on head 58db485:

• Merged current main at 15ff39c.
• FTW #788 has merged, so the Optimizer fixture and comments now match python:3.14-slim-trixie.
• Checked the .local text against Home Assistants plugin-dns source and the mdns-repeater source. The DNS plugin does call systemd-resolved, but no such host does not prove that the device is absent, and an mDNS reflector can bridge network segments. The docs now state those limits.
• Local checks pass: repository validation, 79 unit tests, compileall, full image build, health check, Optimizer restart, and persistence smoke test.
• GitHub run 31179798288 passes all five jobs, including amd64 and aarch64 build and smoke.
• There are no inline review threads. The final PR diff stays at four files.

This head is safe to squash-merge.