docs(huxerui): record that wix belongs behind mcpp pack --format, not in the build

Section 4 already argues this descriptor should not declare `xim:wix` --
wix builds an MSI, and a consumer that merely imports huxerui has no use
for it. That is right but incomplete: it treats the declaration as
misplaced when the mechanism it belongs to simply did not exist yet.

mcpp 2026.9.11.1 opened the `--format` value set. `mcpp pack` owns the
mechanism and the universal formats; every other format lives in a package
that declares `mcpp::provides_pack_format("<name>")` in its build program,
unconditionally, and submits its action only when asked. Under that,
`xim:wix` stops being a top-level `[xlings.workspace]` entry provisioned
for every build of every consumer, and becomes a dependency of the feature
that provides `msi` -- reached only by someone actually packing one.

The timeline is the whole explanation:

    HuxerUI v0.3.0 released                 2026-09-10 17:36 UTC
    mcpp 2026.9.11.1 released, --format     2026-09-10 20:34 UTC

`provides_pack_format` appears zero times in v0.3.0's build.mcpp and
rules.cppm. Not a road not taken -- a road that did not exist, by under
three hours.

Recorded rather than acted on: the v0.3.0 tag is immutable and upstream is
out of scope here. What the descriptor CAN do is behave as though the move
had already happened, which is what not declaring wix does -- so a future
0.3.1 needs no change on this side.

Also notes that the two Windows problems are independent: with wix gone
from the build entirely, runtime_pointer_interaction.cpp still does not
compile against MSVC STL 14.51.

Author: Sunrisepeak

.agents/docs/2026-09-11-add-huxerui-plan.md

@@ -290,3 +290,53 @@ The practical rule: **a change to a xim package cannot be verified from this
 repo's CI unless `MCPP_VERSION` also moves.** Raising the pin to 2026.9.11.2
 evicts the cache, which is the only reason the windows leg can now see the
 fixed recipe.
+
+## 12. Where `xim:wix` actually belongs — `mcpp pack --format`
+
+This descriptor declares no `xim:wix`, and section 4 argues that from the
+consumer's side: wix builds an MSI, nothing else in the SDK touches it, and
+upstream's own manifest says an application wanting an installer declares it
+itself. That argument is right but incomplete, and the fuller one arrived three
+hours too late to be in v0.3.0.
+
+**mcpp 2026.9.11.1 opened the `--format` value set.** `mcpp pack` owns the
+mechanism and the two universal formats (`tar`, `dir`); every other format lives
+in a package and the engine dispatches to it:
+
+```cpp
+mcpp::provides_pack_format("msi");                              // unconditional
+if (std::string_view(mcpp::pack_format()) != "msi") return 0;   // conditional
+// … submit the wix action …
+```
+
+*Declare unconditionally, submit conditionally* — the declaration is what lets
+`--format bogus` list what is available. `xim-pkgindex`'s `appimagetool` (#802)
+is the same shape from the tool side.
+
+Under that mechanism `xim:wix` stops being a top-level `[xlings.workspace]`
+entry — which is provisioned for **every** build of every consumer — and becomes
+the dependency of the feature that provides the `msi` format, provisioned only
+when someone actually asks for an MSI. `mcpp test -p huxerui-module` would never
+touch it.
+
+The timeline is the whole explanation:
+
+| | |
+|---|---|
+| HuxerUI v0.3.0 released | 2026-09-10 17:36 UTC |
+| mcpp 2026.9.11.1 released (`--format` opens) | 2026-09-10 20:34 UTC |
+
+`provides_pack_format` appears **zero** times in v0.3.0's `build.mcpp` and
+`rules.cppm`. Not a road not taken — a road that did not exist yet, by under
+three hours.
+
+**Nothing to do here, and that is the point.** v0.3.0's tag is immutable, so the
+descriptor cannot reach this; what it can do is not make the problem worse, and
+not declaring wix is exactly that. When a 0.3.1 or 0.4.0 moves wix behind
+`provides_pack_format("msi")`, this descriptor needs no change — it already
+behaves as though that move had happened.
+
+Note also that the two Windows problems are independent. Even with wix out of
+the build entirely, `runtime_pointer_interaction.cpp` still fails to compile
+against MSVC STL 14.51 (§11 and the `windows-2022` pin). Fixing the packaging
+axis would not have unblocked this leg.