Schema migration discards user edits to built-in commands

## Problem

`migrateConfig` refreshes built-in profiles by replacing each stored profile with a fresh copy from `DEFAULT_CONFIG`, preserving only `enabled`. Any user edit to a built-in command — a changed label, description, style, shortcut, `requireConfirm`, or the command text itself — is silently discarded the next time `SCHEMA_VERSION` is bumped.

The settings UI actively invites those edits: built-in commands are editable in place, with no indication that the edit is temporary.

This came up as a review finding in five consecutive CodeRabbit rounds across #137 and #138, and was deliberately kept out of both, since it changes the mechanism that delivers new commands rather than anything those PRs introduce.

## Why it is not a one-line fix

Wholesale replacement is what makes new built-in commands reach existing users: bumping the schema is how a new profile or command shows up for someone who installed the extension months ago. A merge strategy has to answer questions replacement does not:

- Match stored commands to defaults by what key? `id` is regenerated per `cmd()` call, so the stable key is the command text — which is itself one of the fields a user may have edited.
- When the default's text changes (e.g. `/payload-abort` corrected from `abort`), does the user's edited copy get corrected, kept, or duplicated?
- If a user deletes a built-in command, should migration restore it? Replacement restores it today; a merge that appends missing defaults would too, which may not be what the user wanted.

## Suggested direction

Merge per command rather than per profile: keep user-edited fields, add commands that are new in `DEFAULT_CONFIG`, and leave removals alone. Whatever the rule ends up being, it wants a regression test that migrates a config with a customized built-in command and asserts the customization survives while new defaults arrive.

> [!Note]
> Responses generated with Claude

Start by reading migrateConfig, DEFAULT_CONFIG, and the SCHEMA_VERSION migration path. Decide how commands are matched and how edited, changed, deleted, and newly added built-ins should behave; then add the suggested regression test showing a customized command survives migration while new defaults arrive.

Written by the indexing model from the issue text.