#2767 gatorwalk-factory: remove stage templates and apply; ship examples/ lifecycles instead

Remove the stage-template feature (the template model type and the lifecycle holder's apply method) before go-live, and replace it with an examples/ directory of complete example lifecycles that the skill points agents at.

Why: since triage narrowed it to copy-and-own (#2663, renamed in #2717), the feature is one-time scaffolding that an agent can do by copying YAML and running validate. Nothing uses it. Neither lifecycles/build-swamp-extension.yaml nor lifecycles/swamp-extensions.yaml uses a template, apply, a contract or a $param. The starter templates (#2684) were extracted from those lifecycles, not used to build them. The 2026-09-29 trial on cue didn't touch it either. It costs about 1,400 lines of source and 1,800 of tests, plus a public model type and a method that become API at go-live. Removing it now costs users nothing; after go-live it is a breaking change.

Scope:

• Remove models/template.ts, _lib/apply.ts, _lib/stage_template.ts, the apply method and its section of _lib/work_item_ops.ts, the contract and $param parts of lifecycle_schema.ts, the template-only branches of graph.ts, and their tests (apply_test.ts, stage_template_test.ts, template_test.ts, templates_test.ts, and the apply integration tests in integration/cli_test.ts). Also remove templates/ and testdata/lifecycles/starter-sketch.yaml and apply-target.yaml.

• Add examples/ with a few complete, validating lifecycles of different shapes. At least:

  • a minimal hello-world (today testdata/lifecycles/minimal.yaml)
  • a generic plan → review → implement → review → verify starter (today testdata/lifecycles/starter-core.yaml)
  • build-swamp-extension

  Each example gets a short header comment saying what it is for and what to change first. Decide whether lifecycles/ moves into examples/ or stays as the lifecycles this repo actually runs (swamp-extensions.yaml does), and say why.

• A test that every file in examples/ passes validate with no errors, so examples cannot rot.

• Skill: one short note telling agents authoring a lifecycle to start from the closest example in examples/, copy it and run validate. Don't write the full authoring guide; that is separate work.

• README and DESIGN.md: remove the template/apply sections. Add a decision-log entry recording why the feature was cut and what replaced it.

Decide during planning:

• The one guarantee apply gave that validate does not: a contract input read only by a CEL binding is produced on every path (DESIGN.md, the productsMissingOnEntry discussion). Say whether any of that check is general enough to keep as a validate finding, or whether #2680 covers enough of it. Don't grow scope into #2680 itself.
• Model version and upgrade handling. #2696 (check_upgrades fails an extension with no manifest) blocks version bumps before go-live. Check whether removing a model type needs a bump at all while the extension is unpublished.

Out of scope: #2680 (CEL product references), the authoring or interview skill, and any studio or design-page work.

Done: the template model and apply method are gone, examples/ exists with validating examples under test, the skill points at it, the docs are updated, and all checks pass.