Tell tools where to write their output

[jorgeMFS]

Stacked on #32 — base it on test-wasm-tools, not master. It edits the same function.

The problem

Nothing ever passed an operation's declared output flag. The command was built from parameters and inputs only; output_def was read solely for the name, mode and types. So a tool whose output is a file was never asked to produce one, and the check could only ever report it missing.

That is 45 of the 186 declared outputs in the catalogue — every one of them structurally unable to pass or fail on its actual result.

The change

The shape follows what the frontend already does when it builds an invocation: a flag and a target, or a bare target when the flag is the empty string, using the recipe's filename when it declares one. Where no flag is declared there is still no way to say where output should go, so those are left alone.

Discovery now looks for the name the tool was told to write, before falling back to matching a file whose stem happens to equal the output name — which is all that was possible before.

Argument order was the bigger half

Chasing why tn93 still failed turned up a second fault, and it was the one actually doing the damage. A filename with no flag was appended as soon as it was built, so it landed ahead of every flag that followed. A getopt-style parser stops scanning at the first non-option, so those flags were never seen:

input_in.txt -o out.txt   ->  prints usage, exit 1, no output
-o out.txt input_in.txt   ->  runs, writes out.txt

Flagless arguments are held back and appended last now, matching what the frontend already does.

Effect on real recipes

Built and tested with the hub's own pipeline on the five wasm-only emscripten recipes:

recipe	before	after
edlib, abpoa, cgranges	pass	pass, unchanged
tn93	Output file not found	passes clean — writes ID1,ID2,Distance, exit 0
fermi-lite	Empty output	unchanged — its output is stdout, no flag applies

Nothing turns red, and tn93 goes from a warning to a correct result: a header row with no pairs, which is right for a single sequence.

One thing worth recording, because it contradicts what I assumed: the richer fixture is the broken one. Handed the Multi-FASTA example instead, tn93 exits 1 and writes nothing — its two records are 99 bp and 100 bp, and tn93 requires an alignment. So "give the fixtures more content" is not the fix it looks like; a multi-record FASTA is not an alignment.

What this does not fix

Both remaining warnings are limits of the example inputs, not of the tools:

• fermi-lite is an assembler given a single 98 base read

And the pass criterion is still lenient — empty output detects as TEXT where TEXT is accepted (67 outputs), and a missing file is only a warning. Making either fail would turn recipes red for reasons the fixtures cause rather than the recipes, so it belongs after the fixtures improve. That is the natural next change, and deliberately not this one.

Merge order

Stacked on #32. Both are independent of sbom-implementation, which does not touch hub/tests/.