Add an upgrade command; there is no way to move an existing install forward

[charlesgreen]

There is no upgrade path

init deliberately does not overwrite. Re-running it on an installed repository prints:

left existing .github/simplycubed.yml unchanged
left existing .github/workflows/simplycubed.yml unchanged

That is the right default — it cannot clobber a gate someone tuned — but it means the product has no way to move an existing install forward. simplycubed/corp was upgraded twice today, and both times the caller was brought up to date by generating a fresh one in a temp directory and copying it over by hand. That is not a procedure anyone should be asked to repeat, and it is exactly the kind of manual step that gets done wrong once and then silently stays wrong.

It matters more than it looks because the agent cannot do this for them. The caller lives under .github/workflows/, which the App holds no permission to push. So upgrading is a human or local-CLI action by nature, which is precisely why it should be one command rather than a copy.

Suggested shape

$ simplycubed upgrade
.github/workflows/simplycubed.yml
  -  uses: simplycubed/code/.github/workflows/simplycubed.yml@v0.1.9
  +  uses: simplycubed/code/.github/workflows/simplycubed.yml@v0.3.0
.github/simplycubed.yml
  +  appName: acme-code

2 files would change. Re-run with --write to apply.

Requirements worth stating, because each is a way this could go wrong:

• Show the diff and require --write. It touches a workflow file, and a surprise rewrite of one is worse than no command.
• Preserve everything the adopter set. The gate above all, plus engine, review, labelPrefix, prDescription. Regenerating from a template and losing a tuned gate would be a far worse bug than the one this fixes.
• Add new required keys rather than only re-pinning. v0.3.0 introduced appName:; an upgrade that bumped the tag and left the config short would produce an install that fails preflight.
• Be idempotent. Running it on a current install reports no changes and exits zero.
• Refuse a dirty tree, or at least say so, since the point is a reviewable diff.

Interaction with #130

If adopters move to a moving major tag, the tag half of this becomes unnecessary and the config half does not. Worth deciding #130 first, since it changes what upgrade is for: re-pinning plus schema migration, or schema migration alone.

Acceptance

• simplycubed upgrade reports what would change and writes nothing
• --write applies it, and a second run reports no changes
• A tuned gate, engine, review, labelPrefix and prDescription all survive
• Config keys a release added are inserted, not just version pins rewritten
• preflight passes on the result, which is the check that config and trigger agree