Emit both `<platform>` and `<platform>-dev` keys in packaged manifest `main`

[fryorcraken]

Problem

The packaging step emits a single platform variant key per build:

• .#lgx (dev build) → manifest.json main: { "linux-amd64-dev": "…" }
• .#lgx-portable (release) → main: { "linux-amd64": "…" } (no -dev)

Basecamp's variant resolver looks up a fixed key at runtime:

• Dev basecamp (scaffold-launched) expects <platform>-dev.
• Release basecamp (AppImage) expects <platform>.

If a module was built as .#lgx-portable and installed into a dev basecamp (e.g. via lgpm install --file …lgx-portable by mistake, or from an in-app Package Manager catalog that only serves the portable variant), dev basecamp's resolver finds no matching -dev key and silently hangs the UI on first click (QRO sync-IPC timeout, ~20 s, then the plugin's state machine wedges).

Verified at master HEAD (4987fed5b7a9300f8c2e40f5a2a60c35d453686c, 2026-04-21): DUAL_VARIANT is referenced nowhere in logos-module-builder, even though the underlying logos-co/nix-bundle-lgx already supports a DUAL_VARIANT=1 env mode (bundle.sh lines 15–17) that adds both a release and a dev variant to the same .lgx. The module-builder simply never invokes that mode.

Observed in the wild

From @vpavlin's review of logos-scaffold PR #75 (logos-co/scaffold#75 (review)):

a bunch of the .lgx artefacts I consumed … end up with manifest.json main keys of linux-amd64 instead of linux-amd64-dev. basecamp v0.1.1 expects -dev. Symptom: a Basecamp that launches and runs, but clicking the plugin silently hangs (dep-resolver fails variant-matching, times out).

Modules affected: yolo-board-module, jimmy-claw/logos-zone-sequencer-module.

Suggested fix (preferred)

Always emit both <platform> and <platform>-dev keys in manifest.json main — either by defaulting to DUAL_VARIANT=1 in mkLogosModule when both dev + portable derivations are available, or by writing both keys pointing at the same file when the single-variant path runs.

Concretely in logos-module-builder (master):

• lib/mkLogosModule.nix / lib/mkLogosQmlModule.nix — set DUAL_VARIANT=1, DEV_VARIANT=<platform>-dev, DEV_SRC_DRV=<dev-derivation-out> when bundling. The nix-bundle-lgx bundle.sh already handles this end-to-end (see existing "Dual-variant mode" block).

Alternatives considered

• Rename variants consistently so dev + portable builds use identical key names, and teach basecamp's resolver to normalize -dev / non--dev at lookup time. Larger blast radius; touches basecamp too.
• Document the asymmetry in the tutorial + basecamp README so downstream tooling knows the contract. Weakest — doesn't fix the UX, just labels it.

Why dual-variant is preferred

• Backwards compatible: existing consumers that look up one specific key still work.
• Keeps the build-time output format unified (same main shape regardless of which .#lgx* attr was invoked).
• Makes lgpm install from any variant work in any basecamp build, eliminating the "which variant did I build?" class of bugs.
• Infrastructure already exists in nix-bundle-lgx; this is a 2-3 line change in mkLogosModule.

Scaffold workaround

Until this lands, logos-scaffold basecamp doctor (PR #75) walks each installed profile's modules/*/manifest.json and warns when main is missing the current-platform -dev key. basecamp launch additionally prints a one-line pre-flight summary, so devs catch the freeze case before clicking. Both are diagnostic-only — the real fix is here.

Context

This is one of three upstream asks filed during logos-scaffold PR #75's review:

1. This issue (logos-module-builder: emit both variant keys).
2. Pin logos-modules release tag at build time (currently hardcoded to latest) logos-basecamp#167 — basecamp should pin its logos-modules release tag at build time.
3. Document the compatible logos-package-manager pin for tutorial-v1 logos-tutorial#39 — tutorial should document the compatible lgpm pin.

Happy to PR the dual-variant wiring if the direction sounds right.