fix: validate --loadout before the missing-config banner in min session activate - #1153

_{Comment @coderabbitai help to get the list of available commands.}

[inbox-patch:clobber]

This PR would revert recently merged work

Simulating this merge shows it undoing commits that landed on the base branch within the last 3 day(s):

• d392e0051 — 80% of its 5 surviving lines in these files would be undone
  • fix: align min ls table columns with its --json field set (fix: align min ls table columns with its --json field set #1144)
    This is the stale-read failure, not a conflict: the agent read these files before the commits above merged, then wrote the whole region back from that stale read. Git applies it cleanly, so there is no conflict, no failing test, and nothing unusual in the diff summary — see gominimal/inbox#460.

Before merging, restore the reverted region to its state on the base branch. The rest of this PR is unaffected.

If a listed commit is one this PR intends to supersede, say so and merge — this check reports, it does not block.

The [inbox-patch:clobber] flag above is a verified false positive — disregard it

I checked it against the code rather than trusting the tool. Every one of #1144's lines survives this merge; none are reverted.

Re-running the scan's exact filters locally on the same inputs gives total=22 gone=0. Listing them individually shows 22 kept, 0 gone — the min ls table formatting, status_label, and the project_path column are all intact in the merged tree.

Ruled out as causes: the blob-filtered clone (filtered and full clones both yield 30 + lines for d392e0051), main moving between scan and check (origin/main has not advanced since 4a738d4e at 21:03Z), and #1144 not being an ancestor (it is).

The scan computed total=5, small enough that four incidental misses cross the 80% threshold. Tracked as gominimal/inbox#472. The check reports rather than blocks precisely so a miscall like this cannot strand a good fix.

Review of the change itself — looks right

Moving offer_mfile_scaffold after resolve_active_loadouts is the correct fix for the ordering bug: a bad --loadout now errors before anything prints.

I checked the specific risk that the move could break first-run scaffolding — if anything between the old and new call sites read the project's minimal.toml, the scaffold offer could become unreachable. It does not. read_client_config, user_policy_path and read_user_policy are all user-level config, and resolve_active_loadouts reads the loadouts dir. The project path reaches offer_mfile_scaffold independently.

The comment explaining why the call sits there is the right thing to leave behind — without it the next reader would be tempted to move it back up.