Fix start target's kill 0 trap killing the invoking process group under make -n

[AmirF194]

Summary

• The start target's trap 'kill 0' EXIT runs even under make -n, because GNU make always executes a recipe line that references $(MAKE). Under -n the two sub-makes finish instantly, wait returns, and the trap fires kill 0, SIGTERMing the whole process group, not just the recipe's own children. That's what kills VS Code: Makefile Tools runs make -n on folder open from inside the extension host's process group.
• Your suggested kill $(jobs -p) fixes the dry-run crash, but on a real run it only reaches the two sub-make PIDs, not their own children (the actual uvicorn/npm processes). I checked: sending a plain SIGTERM straight to a running make dev-backend does not kill the sleep/server underneath it, since make doesn't forward the signal down. So that version leaves both dev servers orphaned after Ctrl-C.
• Went with guarding the whole real body on $(MAKEFLAGS) instead (the same findstring n check the docs already use to detect dry-run elsewhere in the project). Under -n, start just echoes, like every other target does when it doesn't reference $(MAKE). The real-run trap/wait/kill 0 path is untouched, so Ctrl-C cleanup still works exactly as before.

Fixes #57.

Test plan

• make -n start in a generated project used to send SIGTERM to the invoking process (matches your repro exactly), now exits 0. Added test_makefile_dry_run_does_not_kill_process_group, red on main, green on this branch.
• Full existing test suite passes on 3.11 and 3.12, ruff clean. (3.11 has 22 pre-existing failures in test_routes_integration.py/test_wizard.py, unrelated to this file, same on main.)