Certified RTSP node needs ffmpeg, which no FlowFuse image ships

### Description

The certified RTSP node cannot work out of the box on any image we publish. It shells out to ffmpeg, and ffmpeg is not in our containers. The bundled `ffmpeg-static` fallback is a glibc build, so on Alpine it fails to resolve hostnames and the node produces nothing.

Checked today:

| image | base | ffmpeg |
|---|---|---|
| `flowfuse/device-agent:latest` | Alpine | not present |
| `flowfuse/node-red:latest` | Alpine | not present |

[ffcn-nr-rtsp#34](https://github.com/FlowFuse/ffcn-nr-rtsp/issues/34) fixed the lookup order in v1.0.2 so a system ffmpeg is preferred, and added logging so the failure is visible. That made the workaround usable, but the workaround is still that the customer builds and maintains their own container. Our product tracker has RTSP marked as shipped, so nothing currently reflects that a user has to do this.

The customer who raised it has told us plainly that they don't see a ready RTSP connector, they see stopgap arrangements, and it is stopping them putting FlowFuse into critical projects. This is a supported certified node, so I think we need to close the gap rather than document it.

### Option A: publish an RTSP capable image variant

An extra tag, same Dockerfile plus `apk add --no-cache ffmpeg`, built, scanned and supported by us.

- Only people who want RTSP pay for it. Everyone else's image is unchanged.
- The opt in plumbing already exists. Self hosted admins set the image per Stack (`stack.container`, `driver-k8s/kubernetes.js:100`), so a user can put two instances on it and leave the rest alone. Device agent users change a tag.
- It converts "build your own container" into something we ship and stand behind, which is the part that actually answers the complaint.
- Cost: another tag in a matrix that is already 5 per device agent release, and it has to be in the release pipeline. If it drifts we own a stale image, which is worse than today.
- It does not fix FlowFuse Cloud, where users cannot choose a container. That needs an RTSP stack offered separately.

### Option B: add ffmpeg to the images everyone uses

- The node works on install, everywhere, with no docs and no decision for the user. Simplest story, and it covers FFC too.
- Cost, measured on the device agent image: +45 MiB and 97 extra packages (183 to 228 MiB, 61 to 158 packages). Alpine's ffmpeg pulls in x264, x265, vulkan, pulseaudio, libass, bluray and more, none of which we need for RTSP in and PNG out.
- That is a permanent CVE surface in an edge image for something most users never touch.
- Alpine builds ffmpeg with `--enable-gpl --enable-version3`, so we would be shipping GPLv3 binaries in our images. Probably fine as mere aggregation, plenty of commercial images do it, but I would want that confirmed rather than assumed.

### Suggestion

Option A. It is narrower, it runs on plumbing we already have, and it gives users something supported without committing us to carrying ffmpeg for everybody. Happy to be talked out of it if the licensing and CVE points turn out not to matter, because B is a much nicer experience.

### Requested By

https://app.hubspot.com/contacts/26586079/record/0-2/210431677688

### Related

- [ffcn-nr-rtsp#34](https://github.com/FlowFuse/ffcn-nr-rtsp/issues/34)
- #142
- #344

Start by inspecting the image Dockerfile and release pipeline, then review the existing image selection plumbing at driver-k8s/kubernetes.js:100. Compare the two proposed image strategies, including the stated size, package, CVE, licensing, and FlowFuse Cloud constraints. Done means an agreed supported RTSP image approach is implemented and released, or the decision and product coverage are explicitly recorded.

Written by the indexing model from the issue text.