Clear active pause points before running tests

[hatayama]

Problem

PR #1687 added a preflight guard that rejects run-tests when the Editor is already paused. However, a residual limitation remains: if a pause point is armed (enabled but not yet hit) and fires mid-test, the Test Runner itself stalls because EditorApplication.isPaused = true prevents UnitySynchronizationContext from draining continuations. This hang is not solvable at the tool layer.

Solution

Clear all active pause points (including Harmony unpatching) at the run-tests entry point, after validation passes but before test execution begins.

Why this is safe

• PlayMode tests with Domain Reload enabled already destroy all Harmony patches on entry — this makes the behavior explicit and uniform across all test modes.
• The IPC server is single-flight (UNITY_SERVER_BUSY), so re-arming a pause point mid-run is impossible via CLI. Entry-point clearing fully closes the "pause point fires during test" path.
• The only remaining pause source is a human manually pausing via the Editor UI, which is native Unity behavior and out of scope.

Design

1. Clear only after validation passes — rejected calls produce zero side effects (Fail Fast).
2. Use the same implementation path as clear-pause-point --all (registry ClearAll + patcher unpatch). No logic duplication.
3. Report cleared IDs transparently: add ClearedPausePointIds (string[], null when no markers cleared) to the run-tests response. Additive field, no protocol version bump.
4. Clear uniformly for both EditMode and PlayMode, regardless of pause point type (source file:line or manual --id markers).
5. Update the #1687 why-comment in RunTestsUseCase to reflect the new guarantee.
6. Update the run-tests SKILL.md with a note about automatic clearing.

Out of scope

• Human-initiated Editor UI pause during test runs (native Unity behavior).
• Pause point re-arm during test execution (structurally impossible due to single-flight server).

[hatayama]

Resolved by #1690 (merged to v3-beta).