fix: make bundle step refresh rollback transactional

[mvanhorn]

Description

Installed-step refresh with network access now snapshots the package and registry entry, copies the backup, and removes the step inside _step_install_transaction, using command_remove._remove_step_locked so the same non-reentrant flock is not taken twice, while the catalog reinstall stays outside the lock. On BundlerError, rollback acquires that lock again, rereads step-registry.json, and restores the backup and the original metadata only when the step id is missing, assigning the saved entry verbatim so installed_at and updated_at stay unchanged. When the id is already present, the later package and the rest of the reread registry are left in place. A failed copy or registry write is attached with add_note and the original install error is re-raised with the backup kept on disk; lock failure before a snapshot is wrapped as BundlerError, offline and not-yet-installed refresh still delegate to install without a backup, and the tests assert those lock, concurrency, and error-preservation paths.

Refreshing an installed custom step and then failing the reinstall could replace a newer copy of that step and its registry entry with the backup taken at the start of the refresh, and it could drop other step entries committed in between. If copying the backup back or writing the registry failed, that secondary error is what the caller saw, and the temporary backup was deleted. The package and metadata were snapshotted and the step directory was backed up before removal, outside the lock shared with step add and step remove, and the failure path then copied that backup onto the step directory with dirs_exist_ok. StepRegistry.save() replaces the entire registry file from the in-memory document loaded in the constructor, so a snapshot taken before a concurrent update overwrites entries committed later. An exception from the copy or the save propagated in place of the original BundlerError, and the cleanup that followed always removed the backup directory.

Fixes #4815

Testing

• Tested locally with uv run specify --help
  Not claimed: ran uv run python -m pytest tests/test_agent_config_consistency.py -q locally; it fails the same way on the base branch, so the failure predates this change (it fails the same way on main).
• Ran existing tests with uv sync && uv run pytest
  Not claimed: uv sync && uv run pytest was not run locally either.
• Tested with a sample project (if applicable)
  Not verified: this needs a person on the named hardware or environment.

Ran uv run python -m pytest tests/test_agent_config_consistency.py -q locally; it fails the same way on the base branch, so the failure predates this change (it fails the same way on main). Tests for this live in tests/specify_cli/bundles/test_primitives.py.

AI Disclosure

• I did not use AI assistance for this contribution
• I did use AI assistance (describe below)

AI disclosure

AI was used for assistance.

• Extent: AI wrote the code changes and drafted this description.