fix(module): zi module -B assumes autotools; zpmod:develop already migrated to CMake

[ss-o]

Summary

zi module -B / .zi-build-module (both main and next) hardcodes an
autotools build (./configure && make) for zpmod. zpmod's develop
branch (open as zpmod#61, CI
green, mergeable: CONFLICTING against main) has fully replaced that build
system with CMake — there is no configure script and no top-level
Makefile on develop at all.

If zpmod:develop is promoted to zpmod:main before zi's build-module code
is updated, zi module -B (and its main-branch equivalent zi module build) will break for every user on first use.

Repro

zsh -f -c '
  export HOME=$(mktemp -d); export ZDOTDIR=$HOME
  source /path/to/zi.zsh
  zi module -B          # clones/builds zpmod:main -> succeeds (autotools)
'

Then, with the same zmodules/zpmod checkout switched to develop:

-- ./configure --
.zi-module:50: no such file or directory: ./configure
-- make --
Build failed…

Evidence

• zpmod:develop (7add133, 159 commits ahead of main) builds cleanly via
  scripts/cmake.configure.zsh --generator make --build-type Release --ctest
  and its full CTest suite passes 100% (37/37 tests) — the migration itself is
  sound.
• zi's .zi-build-module (lib/zsh/autoload.zsh, both main and next)
  only ever runs ./configure && make; there is no CMake-aware path.
• Related in-flight promotion-readiness work: ci: add promotion readiness gate #379, ci(contract): add public impact gate #383 (both currently
  gate on unrelated z-shell/zd dependencies and don't cover this gap).

Ask

Before promoting next → main, or before zpmod#61 merges (whichever
lands first), give .zi-build-module a CMake-aware path (e.g. detect
CMakeLists.txt at the module root and shell out to
scripts/cmake.configure.zsh, falling back to ./configure && make only
when a legacy configure script is present), and add a smoke test that
actually zmodloads the built module rather than only checking that the
build step exits 0.

Type of change

• fix — bug fix (non-breaking, forward-compatibility gap)