Make EVM feature-script stripping robust to template script renames

[fernandomg]

Summary

When an EVM feature is deselected in custom mode, patchPackageJsonEvm (source/operations/cleanupFiles.ts) strips the feature's scripts from the generated package.json by hardcoded script name (subgraph-codegen, typedoc:build, docs:build / docs:dev / docs:preview, …). If the upstream dAppBooster template renames one of these scripts, the strip silently misses it, leaving a dangling script that invokes files cleanup already removed. Same class as #8 (a manifest left referencing removed code), but for EVM scripts. The Canton stack already strips by command target (scriptTargetsRemovedDir), so it is immune.

Reproduction

Latent — triggers on the next upstream script rename. To force it today:

1. In the dAppBooster template, rename subgraph-codegen → e.g. subgraph:codegen.
2. npx dappbooster --evm --ni --name test_drop --mode custom --features demo,typedoc,vocs,husky (subgraph deselected).

Expected

The generated project's package.json contains no script that invokes a removed feature's files — regardless of the script's name.

Actual

Only scripts whose names match the hardcoded list are stripped. A renamed script survives and still references src/subgraphs (removed), so the generated project ships a dangling, broken script.

Impact

1. Silent at scaffold time (no error).
2. Generated project ships a script that fails when run.
3. Brittleness scales with every EVM template script rename — cleanup correctness depends on script names staying frozen.

Suggested fix

Converge EVM onto Canton's target-based stripping: drive removal from the deselected feature's removed paths (the directory a command invokes) rather than a hardcoded name list. Add a test for a renamed-script scenario.

Out of scope

Canton (already target-based). The broader EVM/Canton cleanup convergence beyond script stripping.