flash --dry-run returns ok:true for a manifest it never validated, whenever SETOOLS resolves

[alpCaner]

Found while reviewing

feat/v06-batch at 13891f1.

python/tan/commands/flash_cmd.py:1020-1028. When SETOOLS_DIR resolves, the SETOOLS branch returns a preview and exits before meta.build(...) (:1039) and before validate_flow_d_preflight_args (:1057-1063).

validate_flow_d_preflight_args's own comment at :1048-1056 says it exists precisely so tan flash --dry-run on a half-armed or malformed manifest stops reporting ok with no diagnostic. The new early return reopens exactly that hole, and only on hosts where SETOOLS is installed — so it is invisible to anyone without it.

Reproduction

Both with SETOOLS_DIR resolving:

flash_args:
  jlink_flash_device: AE822FA0E5597LS0_M55_HE
  slot0_load_address: "0x80010000"
  expect_dpidr: "not-hex"

exitCode 0   status "ok"   issues []

The same manifest with SETOOLS_DIR unset is a refusal:

flash_args.expect_dpidr is present but flash_args.jlink_device is not -- refusing to
silently skip the pre-write SW-DP IDR check

So the dry run green-lights a manifest whose SW-DP IDR guard is disarmed — the guard that, on a bench where two probes share the cloned serial 603000869, is what distinguishes the AEN E8 (0x4C013477) from the GD32 bridge (0x0BE12477) before a write.

Second case, output_artefact: zephyr.hex with no sibling .bin:

exitCode 0
would sign ...\build\zephyr.hex with SETOOLS at ...

The same function refuses that artefact fourteen lines later (flash_cmd.py:852-861, "SETOOLS needs a raw .bin to sign") on a real run. That is the ELF-vs-.bin question answered two different ways inside one function, selected by --dry-run.

Impact

--dry-run is what a customer runs to find out whether a flash is safe before touching MRAM. Returning ok:true for a manifest that a real run refuses inverts its purpose. It is also the shape of defect this repo keeps filing (#299, #301, #306, #310, #350, #355): a verdict reported without the check that would justify it.

Acceptance criteria

• The raw-.bin resolution/refusal (flash_cmd.py:852-861) moves ABOVE the if ctx.dry_run: at :838, so both paths answer the artefact question identically.
• The dry-run path falls through to meta.build and validate_flow_d_preflight_args and reports their outcome, with a preview-only marker rather than an early return.
• A dry run whose real run would refuse reports that refusal, with the same issue code and message.
• Tests cover both reproductions above, with and without SETOOLS_DIR resolving, and fail against current main.

Related: #353, #312.

[alpCaner]

Fixed on dev in ac79d4c (PR #352), and verified by running that freeze in a pristine ubuntu:24.04 carrying only ca-certificates, git, python3 -- not by code presence.

dev IS this repo default branch, so Closes does fire here; this issue was filed after the PR body closing-keyword list was written, so it was never in it. Closed by hand -- a merged PR body cannot close retroactively.

The remaining fa_*_checked reads are hoisted into validate_flow_d_shape, the one function both the SETOOLS --dry-run preview and the real plan_alif_mram_jlink call first, so a malformed manifest can no longer pass a dry run and be refused on the real one -- after app-gen-toc had already written into the customer SETOOLS install.

Measured in the container: flash --dry-run returns rc=1, envelope.exitCode=1, ok=False. The CLI-wide invariant process exit code == envelope.exitCode holds.