Clear resolved patch errors after discard

[juanmaguitar]

Why

After a contributor chooses Discard this ticket to its base from a failed Revert, the discard succeeds but the old red patch error remains on screen. The checkout is clean, yet the interface still claims the operation failed.

The original #325 belonged to the stale stack that GitHub closed while #324 was being recovered, so this PR lands the already approved fix directly on trunk.

What changes

After a successful discard, clear the stale apply error and related preview state. If discard fails, retain all of that state so the contributor can still understand and recover from the failure.

How to test this

Platforms: macOS and Windows.

Starting state: ticket #65819 linked, PR #13017 applied, with this contributor edit on an applied line in tests/phpunit/tests/customize/widgets.php:

$this->assertIsCallable( $args['sanitize_callback'], 'sanitize_callback is callable' ); // Mi cambio.

1. Click Revert this patch. Revert must be rejected, the checkout must remain unchanged, and the red error must offer Save a copy of your work and Discard this ticket to its base.
2. Click Discard this ticket to its base.
3. The applied PR, contributor edit, applied-layer card, and red error must all disappear. Ticket #65819 must remain linked.

What must not have happened:

• A failed discard must not clear the error or preview state.
• The ticket itself must not be unlinked.
• No unrelated ticket work may be removed.

This flow passed in the approved integration artifact at commit 012d7df on macOS and Windows.

Risks and limitations

The final Git tree is exactly the tree manually approved for the release candidate. Self-review: 0 [fix here] · 0 [follow-up].

Related

Replacement landing for #325. Follow-up to #318 and #330.

---

Design decisions and alternatives considered

The cleanup is derived in the existing pure reducer and only committed after outcome.ok. Keeping failure state unchanged avoids hiding recovery information after an unsuccessful destructive operation.

A standalone PR avoids reusing the closed stack topology that caused #324 not to land on trunk.

Review outcome (required — see AGENTS.md)

0 [fix here] · 0 [follow-up]. Lint, 1010/1010 tests, and git diff --check pass. The branch resolves to approved tree d3904782d5e434df8591e99d3ccf2a49a52ebcc9.

Implementation notes

Recovery head before squash: 6a88a26. It contains one commit directly on #330's squash commit.

Screenshots or recording

The user-visible flow was manually validated on both target platforms in the approved integration artifact.