calque real's [3/8]/[5/8] progress lines say "vLLM"/"vLLM load" even when --script picked a real non-vLLM unit (Dockerfile-build or host-mode path)

[scttfrdmn]

Context

Found while running a real calque real --script .../blending_app.py --function inspect_netcdf_bundle --item-file ... --pip xarray --pip netCDF4 invocation against real AWS (a plain CPU function, no vLLM anywhere in the picked unit).

cmd/calque/realrun.go:

• Line 380-381: the [3/8] message correctly branches on hostMode — but a --script run whose resolved image needs an ON-INSTANCE DOCKERFILE BUILD (calque#177's buildDockerfile path, image.NeedsBuild) is neither hostMode NOR the default hardcoded-vLLM path. It still hits the else branch and prints "wrote manifest (%d real prompts, vLLM @enter+@method)" — actively wrong, since the manifest ships the script's own picked unit's real body (confirmed directly: I inspected the actual manifest.json in S3 and it correctly carried inspect_netcdf_bundle's real body, not vLLM's — this is a display bug only, not an execution bug).
• Line 517: fmt.Printf("[5/8] waiting for warmd summary (vLLM load + %d generations)...\n", o.n) is UNCONDITIONAL — always says "vLLM load" regardless of hostMode/buildDockerfile/registryRef/default.

Real console output from that run:

[3/8] wrote manifest (1 real prompts, vLLM @enter+@method)
...
[5/8] waiting for warmd summary (vLLM load + 1 generations)...

— despite the run driving inspect_netcdf_bundle (an xarray-based NetCDF inspector), never vLLM at all.

Why this matters

This is confusing/actively misleading for anyone using --script to drive a real non-vLLM workload (which is the entire point of --script/--function) — the progress output claims something false about what's actually running on the instance, right as a real bill starts accruing. Doesn't affect correctness (confirmed the real manifest/body shipped correctly) — purely a user-facing message bug.

Ask

Make both messages branch on the actual mode (hostMode / buildDockerfile / real registryRef / default-vLLM), the same way [3/8] already tries to for hostMode alone — just extend that branching to cover all four cases, and apply the same fix to [5/8]'s message. Something like:

• host-mode: "%s's own @enter+@method" (already correct)
• build-mode: "building %s's own resolved image on the instance, then %s's own @enter+@method"
• registry-pull mode: "pulling %s's own resolved image, then %s's own @enter+@method"
• default (no --script): "vLLM @enter+@method" / "vLLM load" (unchanged)

Same fix likely applies to fleetrun.go's equivalent progress lines if they have the same unconditional-vLLM wording — worth checking while in there.