fix(cli): scaffolded controllers 404 on a missing or soft-deleted record

[bpamiri]

show, edit, update and delete called findByKey bare. It returns a non-object for both a missing key and a soft-deleted row (deletedAt set), so the action operated on an empty value and the view threw — a 500 where a 404 belongs. Reproduced on a soft-deleted post during the demo rehearsal. The crud and api-resource generators already guard this; the scaffold was the outlier.

The fix

A requireRecord before filter throws Wheels.RecordNotFound, which the framework maps to 404:

filters(through="requireRecord", only="show,edit,update,delete");

private function requireRecord() {
    if (!IsObject(model("Post").findByKey(key=params.key))) {
        Throw(type = "Wheels.RecordNotFound", message = "Post not found for the requested key.");
    }
}

It deliberately does not assign the record. The actions keep their conventional single-finder body, which the --belongsTo parent wiring depends on — ScaffoldSource.showInclude() only rewrites show() when the finder is its entire body, so an inline guard there silently disables include= wiring. Loading twice is cheap and preserves that contract.

Why the first three attempts failed

Worth recording so nobody repeats them.

ScaffoldSource.scan() fails closed on any interpolated string. A single #params.key# anywhere in the file returns valid=false; method() then can't find show(), and the parent wiring reports "skipped". My guard's message was interpolating the key. It's now a plain string — and the new spec asserts the generated file scans, so this can't regress quietly.

A spec forbids the bare positional findByKey(params.key) anywhere in the controller (the mixed positional+named form is rejected at runtime). The filter uses the all-named form.

Verified on a generated app

request	before	after
/posts/12 (soft-deleted)	500	404
/posts/99999 (never existed)	500	404
/posts/12/edit	500	404
/posts/1 (real)	200	200, eager-loaded comments still listed

That last row is the one that proves the --belongsTo wiring survives.

CLI suite: 1356 pass, the 4 pre-existing DbCommandSpec failures, 0 errors. Complexity gate: PASS.