feat(han-planning): add plan-a-change for architecture-driven code changes

[mxriverlynn]

Summary

• Adds /plan-a-change to han-planning: a skill that plans an architecture-driven change to code that already exists, producing a plan plan-work-items, tdd, or refactor can build from directly.
• Review the surface delta rule and the behavior-preservation gate closely. Those two carry the design.
• No version bumps and no CHANGELOG entry. Adds reciprocal boundary clauses to architectural-analysis and plan-a-feature so disambiguation works in both directions.

Why

Issue #183 names a gap between two existing skills. architectural-analysis assesses an area and produces findings, then stops. plan-a-feature specifies behavior a user observes, and its content rule keeps symbol names out on purpose. Neither answers "these responsibilities are wrong, plan the fix", so the author of that issue hand-orchestrated structural-analyst, behavioral-analyst, and software-architect and synthesised the result themselves.

The issue makes three asks. This PR answers all three in one skill:

Code-level names are the subject, not a leak. The plan names types, modules, and methods, because it plans a structure an engineer works in rather than behavior a user observes. The altitude limit is different in kind: carry names, responsibilities, and contracts; never inline file bodies or prescribe line-level edits.

The surface delta is a target-state record, not a migration table. Five verbs, and every entry states what is true after the change in its own right, written so it would still be correct if every other entry were deleted. A removal always says where the responsibility went, or that it went away and why. This is the fix for the issue's "one removal had no target-state statement anywhere". A migration table is written from the call site inward, so a responsibility moving between two internal collaborators produces no row at all and vanishes from a document built that way.

Behavior preservation is a gate, not an assumption. Every delta entry is classified preserving, changing, or unknown. The last two are escalated before commit. An entry that cannot be classified is escalated rather than assumed safe.

Closes #183.

What it does

Twelve steps: establish the reason, record the scope boundary, establish the current state, select the team, propose the target state, settle the delta, run the behavior gate, review, sweep for YAGNI and scope, write, readability, present.

Two behaviors worth a reviewer's attention:

• The reason is recorded and not assumed. Step 1 classifies why a change is being planned across six reason classes. A reported defect is one of them; a prior findings report is another. Neither is presumed to exist. A run with no recorded reason stops, because there is nothing for the YAGNI evidence test to test against.
• Discovery is conditional. With a prior report, Step 2 reads it. Without one, Step 2 dispatches structural and behavioral analysts (plus concurrency on signal). That is the orchestration the issue describes doing by hand.

The output folder resolves through the config-rule precedence chain, so output-directory from either .han/config.md governs it.

How to verify

• npm run lint and npm test (95 tests, all passing on this branch).
• Read han-planning/skills/plan-a-change/references/surface-delta-rule.md, the file the issue's central complaint maps to.
• Check the boundary clauses in three descriptions read correctly against each other: plan-a-change, plan-a-feature, and architectural-analysis. All three stay under the 1024-character target (765, 783, 843).
• Confirm the docs coverage rule holds: long-form doc at han-planning/docs/skills/plan-a-change.md, scent line in the plugin README, entry in docs/skills/README.md, chain entry in docs/workflows.md.

Risk / rollback

Low. The change is additive: one new skill plus registration across the docs surfaces. The only edits to existing behavior are two description clauses and four consumer-list lines in the shared planning rules, none of which change what an existing skill does. plan-a-change uses the boundary record from planning-boundary-rule but not its visual-material convention, which is stated in the rule's consumer note. Revert with git revert.