install.sh -a loader: an explicit ZI_HOME is not propagated to the loader block, so startup clones a second Zi

[ss-o]

Summary

install.sh -a loader honours an explicit ZI_HOME (and ZI_BIN_DIR_NAME) for the clone, but the loader block it appends to .zshrc only sources init.zsh and calls zzinit; nothing propagates those values. init.zsh then resolves ZI[HOME_DIR] from the legacy and XDG homes only and defaults ZI[BIN_DIR] to $ZI[HOME_DIR]/bin, so on first shell start it clones a second Zi at the default location and the checkout the installer just created is never used.

Where

main at a1ac6d2:

• public/sh/install.sh, the -a loader block in MAIN_PROFILE: no ZI_HOME or ZI_BIN_DIR_NAME in the generated text.
• public/zsh/init.zsh:62-96: home resolution reads ZI[HOME_DIR] and ZI[BIN_DIR] only when already set.

Evidence

Found while reviewing the zi-install skill delivery (z-shell/.github#638, #216): the Loader profile cannot be verified against an explicit ZI_HOME because verification and startup use a different checkout than the install. The default profile is unaffected: its block writes the literal home into the source line.

Expected

The loader block sets ZI[HOME_DIR] (and ZI[BIN_DIR] when ZI_BIN_DIR_NAME was overridden) in typeset -gA ZI before sourcing init.zsh whenever the installer ran with an explicit ZI_HOME, in the same quoted form the default block uses; tests/installers.sh gains a case that installs the loader profile with ZI_HOME set and asserts the block carries it. Until then the zi-install skill restricts ZI_HOME overrides to -i skip. Related: the planner design in #208 (item 6 names this gap for migration).