mcpp new --template imgui fails on all platforms: package 'imgui@1.92.8' has no mcpp.toml

[Sunrisepeak]

Summary

mcpp new <name> --template imgui fails on all three platforms in the
post-release / scheduled ci-fresh-install workflow:

 Downloading compat.imgui v1.92.8
error: package 'imgui@1.92.8' has no mcpp.toml

The step is Template: mcpp new --template imgui (fetch path), and it fails
identically on Linux fresh install, macOS fresh install and
Windows fresh install.

Not a 0.0.102 regression

Found while verifying the 0.0.102 release, but it predates it. The error text
is byte-identical in the scheduled run that executed before the 0.0.102
batch landed:

run	date	mcpp	result
29736516661	2026-07-20	0.0.101 release	all jobs green
29814932554	2026-07-21 08:36	scheduled	error: package 'imgui@1.92.8' has no mcpp.toml
29873685262	2026-07-21 22:30	0.0.102 release	same error, same package, same version

So the regression window is between 2026-07-20 and 2026-07-21 — after
0.0.101's post-release verification passed and before the July 21 schedule.
Nothing in mcpp released in that window, which points at the package/index
side (compat.imgui 1.92.8 or the template's fetch path) rather than at the
engine.

Where to look

• compat.imgui at 1.92.8: does the payload actually carry an mcpp.toml,
  or is it expected to be synthesized from the descriptor's mcpp = { ... }
  segment? The message comes from the template/scaffold fetch path, which
  looks for a manifest inside the fetched package.
• Whether the template flow and the ordinary dependency flow disagree about
  which of those two forms is acceptable — an ordinary [dependencies] use
  of compat.imgui is not reported failing, which would make this specific
  to the scaffold path.

Secondary observation in the same runs

The same jobs print

error: index requires mcpp >= 0.0.101 but this is mcpp 0.0.100 [E0006]

That one was the workspace bootstrap pin in .xlings.json lagging the index
floor; fixed by b5dece0 (pin -> 0.0.102). It is unrelated to the template
failure, which continues after it.

Environment

ci-fresh-install on ubuntu-24.04 / macOS ARM64 / windows, mcpp installed
from the published release via install.sh.

[xv1rcn]

Root cause

The namespace discovery loop in fetch_template_package() searches for template packages by bare name. xpkg_lua_candidates("", "imgui") generates ["imgui.lua", "compat.imgui.lua"] — both pass the identity check in discovery mode (only the short name is verified). If imgui.lua is unavailable for any reason (index floor check, partial clone, etc.), the fallback to compat.imgui.lua succeeds.

compat.imgui is a Form B package (mcpp = { ... }): its manifest is synthesized from the index descriptor. The extracted tarball (upstream ocornut/imgui) has no mcpp.toml. The normal dependency path (prepare.cppm) handles this via McppField::TableBody → synthesize_from_xpkg_lua(), but fetch_template_package() did not — it directly checked the filesystem for a physical mcpp.toml and failed with a confusing error message.

Fix

src/scaffold/create.cppm (+4 lines): after reading the xpkg lua descriptor, check mcpp::manifest::extract_mcpp_field(). If the kind is McppField::TableBody, skip to the next namespace candidate via continue. This mirrors the Form A/B dispatch already present in prepare.cppm.

Test

Extended tests/e2e/69_package_templates.sh with a hermetic Form B compat package that reproduces the exact failure. Verified the fix locally and with related E2E tests (02, 12, 27) — no regressions.

PR: #266