fix: report/ is built on the extension it needs

[sotashimozono]

Description

report/ is the one seam nothing in this repository exercises — CI runs compute.jl
and collect.jl but never resolves the render environment, and setup.sh deliberately
leaves it for first use. Both example projects had drifted into two different broken
states behind that gap.

Type of Change

• 🐛 Bug Fix (bug)

Proposed Changes

The two report environments disagreed, and neither was runnable.

	had	missing
ExampleSweep/report	Pinax	ParamIO — but report.jl says using ParamIO
ExampleMonteCarlo/report	ParamIO	Pinax — the render env had no renderer

An indirect dependency cannot be using-ed by name. DataVault brings ParamIO in, but a
script naming it needs the line in [deps], so the one project that had Pinax could not
start its own report script. The root README's claim that report/ carries Pinax was
false for half the template.

Neither report.jl called Pinax. Both ended at @info and a comment saying to draw
here, so Pinax.report(vault, recipe) — the entry point the whole report/ split exists
for — appeared nowhere. That method lives in PinaxDataVaultExt, whose triggers are
DataVault and ParamIO; the core method is an error stub, so a missing dependency surfaced
as a message about DataVault rather than as anything about report/. Both scripts now
call it, with a recipe that builds figures and a table and emits the human gallery and
agent.json together.

The reduction contract was the deeper mismatch. summarise(vault) re-walks the vault,
but Pinax.report has ALREADY discovered the :done keys and loaded each payload before
it calls the recipe — so calling the vault method from a recipe reads every file twice and
leaves no way into the driver. summarise now takes the (DataKey, Dict) pairs, and a
thin summarise(::DataVault.Vault) reads them for scripts/collect.jl, which is
unchanged. One reduction, two entry points: the table printed on the cluster and the
figure drawn afterwards still cannot differ.

julia = "1.12" in both report envs, because Pinax declares that floor and 1.10
advertised one this environment cannot resolve at. The compute envs stay at 1.10
deliberately — a dependency only the render side has must not raise the cluster side's.

Usage or Results

# From a fresh copy of the template
./setup.sh MyStudy FirstSweep
cd projects/FirstSweep
julia --project=. scripts/compute.jl configs/smoke.toml
julia --project=report -e 'using Pkg; Pkg.instantiate()'
julia --project=report report/report.jl configs/smoke.toml
# -> out/report_html/index.html  (human)   out/report_agent/agent.json  (LLM)

Run for real, both projects, from a clean vault:

• ExampleSweep — instantiate → compute.jl → collect.jl → report.jl;
  PinaxDataVaultExt precompiled and loaded, n=4, gallery + agent.json written.
• ExampleMonteCarlo — same, n=2, Binder and magnetisation pages.
• Sample averaging (new code) on a separate collision-free fixture with
  total_samples=2: 8 raw rows reduce to 4 plotted points, the shape a broken grouping
  would get wrong. The arithmetic is not covered — work_fn is deterministic, so the
  samples behind one key are identical.
• The data-aware render cache showed itself: an edit that changed only a plot label was
  not redrawn until the cache was cleared, because the vault data had not changed. That is
  PinaxDataVaultExt._data_fingerprint working.

Found while verifying, NOT fixed here — please decide

ExampleSweep's debug.toml and production.toml collide on disk. ParamIO.diagnose:

config	distinct points	ok	colliding paths
smoke.toml	1	✅	0
debug.toml	4	❌	2 (4 points → 2 directories)
production.toml	20	❌	10 (20 points → 10 directories)

The default path_formatter is the 2-arg ParamIO.format_path, which renders floats with
%.2f. dt = [1e-2, 5e-3, 2.5e-3, 1.25e-3] becomes 0.01, 0.01, 0.00, 0.00, so half the
sweep silently overwrites the other half — the ledger records four done keys while only
two directories exist. ParamIO's own source calls this out ("CONTENT-BLIND … silently
overwriting one run's directory with another's") and ships an auto mode
(build_axis_formats) for it.

CI cannot see this: the project job runs only smoke.toml, the single config with
one dt and therefore the only one that can pass. ExampleMonteCarlo is unaffected — its
kbT values stay distinct under %.2f, and all three of its configs report ok=true.

Left out because it is a separate defect from the one this PR fixes, and the choice between
passing a path_formatter and changing the swept values is yours.

check list

• ./setup.sh を通したか（改名と UUID 再発行が壊れていないか） — MyStudy/FirstSweep
  で実行、placeholder の残りゼロ、改名後の report/ が instantiate して描画まで完走
• projects/ExampleSweep が instantiate できるか — 両プロジェクトとも compute/report 双方
• 新しいファイルを足したなら、setup.sh の書き換え対象に入っているか — 新規ファイルなし
• 施設固有の記述・資格情報を含めていないか

🤖 Generated with Claude Code

[github-actions]

📚 Docs preview: https://qatlashub.github.io/templateHPC.jl/previews/PR7/

(updates on each push to this PR)