fix(blaze): reject incomplete sandbox resets

[WeissonHan]

Why

The reset endpoint returned success after changing only lifecycle metadata and
placing the same running sandbox in the warm pool. It did not reset runtime or
storage contents, so a later warm claim could reuse state that the caller
expected reset to discard.

Before this change, reset could return a false success and mutate lifecycle,
persisted state, pool membership, and metrics. After this change, an existing
sandbox receives 501 Not Implemented before any of those values or its
runtime owner can change.

What changed

• Reject reset for an existing sandbox before lifecycle or ownership mutation.
• Preserve persisted state, runtime ownership, warm-pool membership, and reset
  metrics on rejection.
• Keep invalid and unknown identifiers mapped to their existing errors.
• Move warm-pool setup used by tests into a test-only fixture instead of calling
  the incomplete production endpoint.
• Update the English and Chinese API summaries to describe the actual behavior.

Commit structure

Commit 1, fix(blaze): reject incomplete sandbox resets, contains the API
guard, the invariant regression, test-fixture correction, and the matching
bilingual API summary.

These changes belong in one PR because the code and documentation correct one
false-success contract. Splitting the test fixture or API summary would leave a
revision that either cannot test warm reuse independently or still advertises
behavior the endpoint does not provide.

Still to do

1. Implement successful reset only when runtime and storage can be reset as one
   complete operation; that capability is not part of this bugfix.

Related issue

closes #2288

User / Agent impact

Clients that called the incomplete reset path now receive an explicit 501
instead of a misleading success response. Other instance and warm-pool
operations are unchanged.

Risk and compatibility

• Public CLI, API, configuration, or documented behavior changed
• Privileged or security-sensitive behavior changed
• Cross-component contract changed
• Migration or rollback guidance is needed

This intentionally changes only the unsupported reset response. A client that
treated the old false success as valid must handle 501 until complete reset
support exists.

Validation

Verified on Linux x86_64 for commit
7068096ec2792dc3f630726375f88dd7552f4d8f (tree
7561d64adacf9890587e2448ffe7cf4722a63000, archive SHA-256
790fcd1d72cdc181a856c84149a926f895b2c9af4f7356a5bb59831d1e22e233),
from src/blaze:

• cargo fmt --all -- --check
• default and all-feature locked workspace builds
• default and all-feature strict workspace Clippy
• cargo test --workspace --locked (blaze-core 52, blazed 108)
• cargo test --workspace --all-features --locked (blaze-core 52, blazed 118)
• default and all-feature strict rustdoc
• focused reset regression (1 passed)
• commitlint 19.8.1, trailer parsing, and git diff --check
• documentation lint and relative-link check

Documentation and rollback

The English and Chinese component README files now mark reset as reserved and
returning 501. Reverting the single commit restores the old behavior; no
persisted-data conversion is required.

[WeissonHan]

@codex review Please review exact head 7068096ec2792dc3f630726375f88dd7552f4d8f. This PR makes the incomplete sandbox reset endpoint return 501 before lifecycle, persistence, runtime ownership, pool membership, or metrics can change.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep it up!

Reviewed commit: 7068096ec2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".