…ges on user confirmation

Two new bullets in repo Commit Conventions, both addressing recurring agent
mistakes when classifying their own work:

1. **Type selection by intent, not diff shape.** Net additions on a fix
   (a new guard, a new check, restoring missing behavior) do not turn a
   `fix:` into a `feat:`. Without an explicit rule, agents look at the
   diff, see additions, and pick `feat:`. The new bullet defaults to
   `fix:` for the feat/fix tiebreaker, reserves `feat:` for capabilities
   that did not previously exist, and gives a regression-test heuristic.
   Other conventional types stay primary when they fit better.

2. **Breaking-change marker requires explicit user confirmation.** This
   repo uses release-please, which cuts a major version bump on any
   commit or PR title containing `!` or a `BREAKING CHANGE:` footer.
   Agents cannot make that release decision unilaterally even when a
   change is technically breaking, because the user may want to defer
   the bump, bundle the breaking change, or reframe the API. Replace
   the prior "must be explicit" bullet (which actively invited the
   marker) with a confirmation-first stance.

External research turned up no public AGENTS.md / cursorrules with
explicit feat-vs-fix decision logic; canonical sources stop at thin
spec definitions. The fix-vs-feat phrasing borrows the SemVer reframe
from Conventional Commits and the regression-test heuristic from
Bruno Noriller (Medium, "feat vs fix vs refactor — which is which?").

…scription skills

End users running ce-commit, ce-commit-push-pr, or ce-pr-description in
their own repos hit the same misclassification trap as agents working in
this repo: a defect remedy that adds code gets labeled `feat:` because
the diff shape looks feature-like. The skills' priority orders for
convention selection enumerated the type list but provided no rule for
choosing between types when more than one could fit.

Add a tight runtime rule to each skill: when conventional commits is the
active convention, default to `fix:` over `feat:` for changes that
remedy broken or missing behavior, and reserve `feat:` for capabilities
that did not previously exist. Other types stay primary when they fit
better. Each skill carries the rule inline because cross-skill shared
references are not supported (per plugin AGENTS.md).

Skill-level versions are tighter than the repo AGENTS.md version (no
regression-test heuristic, no full type roster restated) since SKILL.md
content loads on every invocation and the surrounding step already
enumerates the types. End users may override the default via repo
conventions or explicit instruction.