maker-flatpak: documented config requires patching unmaintained upstream deps; recommend doc disclosure or marking experimental

## Summary

The [flatpak maker page](https://www.electronforge.io/config/makers/flatpak) presents the maker as a working, supported configuration. In practice, building a flatpak today against current freedesktop SDKs requires patches to upstream packages that haven't shipped releases in years. Users running `electron-forge make` get an opaque `flatpak-builder failed with status code 1` with no in-product path to the root cause — discovering it requires `DEBUG=*` and reading installer source.

## Concrete blockers shipping a flatpak with the documented config

1. **`@malept/electron-installer-flatpak` doesn't forward `workingDir` / `cleanTmpdirs`** to the underlying bundler — silently ignored. No incremental builds, no inspectable build tree. Filed: [malept/electron-installer-flatpak#131](https://github.com/malept/electron-installer-flatpak/issues/131).
2. **The same package pins zypak to tag `v2021.02`**, whose Makefile uses `clang++`, which the freedesktop SDK doesn't ship. Default builds fail with `make: clang++: No such file or directory`. zypak itself fixed this upstream years ago (current tag `v2025.09` uses `g++`). Filed: [malept/electron-installer-flatpak#132](https://github.com/malept/electron-installer-flatpak/issues/132). Related downstream symptom: [#2805](https://github.com/electron/forge/issues/2805).
3. Adjacent context, same shape on a sibling maker: [electron-userland/electron-installer-redhat#343](https://github.com/electron-userland/electron-installer-redhat/issues/343) / [#344](https://github.com/electron-userland/electron-installer-redhat/pull/344). `@electron-forge/maker-rpm` depends on an installer that hasn't shipped since Feb 2023 and now requires a patch (PR #344, open since Jan 2025) to work on Fedora 41+. Forge users hit this on `npm run make` with no warning.

`@malept/electron-installer-flatpak` last released v0.11.3 in May 2021 (almost 5 years ago). `electron-installer-redhat` last released in Feb 2023. Both are effectively unmaintained.

## The actual gap

Forge doesn't own those packages and isn't on the hook to fix their bugs. But Forge **chose** them as the implementations behind first-party `@electron-forge/maker-*` packages, ships them under the `@electron-forge/` npm scope, and documents them on electronforge.io. That makes monitoring fair to ask for, even when fixing isn't.

The error reporting is also fully opaque through the chain (`forge → @malept/electron-installer-flatpak → @malept/flatpak-bundler → flatpak-builder → make → clang++ not found`). Nothing surfaces beyond "status code 1." A user can't discover the cause from the error, and they can't discover it from the docs either. That's the bug under the bug.

## Recommendations (in order of preference)

1. **Disclose on the maker page.** A short note explaining the maker depends on `@malept/electron-installer-flatpak` (and transitively `refi64/zypak`), that both have known issues requiring patches in current build environments, with links to upstream. Costs nothing, saves every downstream user the same multi-day investigation.
2. **Mark the maker as experimental / community-maintained** in the docs nav.
3. **Surface chain errors better.** At minimum, document `DEBUG=*` on the maker page so users hitting "status code 1" know how to get a real error.
4. **Remove the docs page** until the upstream chain is healthy. "We don't currently support flatpak; here are community alternatives" is a more honest answer than the current implicit "this works."

Happy to send a docs PR for (1) if maintainers are open to it.