feat(stop): explain blocking change conflicts

[tlm]

Description

This improves the workshop stop UX when the stop action is blocked by another
workshop change, especially a refresh that is paused on error.

Previously, if a user ran workshop stop dev while a refresh was paused on
error, the CLI only received a generic daemon error. The output did not explain
which change was blocking the stop or what the user should do next.

Before:

error: cannot stop "dev": waiting on error

After:

error: cannot stop "dev": refresh change is waiting on error
To view details: "workshop tasks 29"

To abort and undo the refresh: "workshop refresh --abort dev"
Otherwise, resolve the error, then run "workshop refresh --continue dev"
After that, run "workshop stop dev" again.

For non-refresh change conflicts, the CLI also now has enough context to show a
more specific blocking-change message:

error: cannot stop "dev": change launch is in progress
To view details: "workshop tasks 30"

Design

This change keeps the existing project layering:

• workshopstate.StopMany remains responsible for deciding whether stop can
  proceed.
• conflict.CheckChangeConflict remains the source of blocking change details.
• The daemon API layer translates typed domain errors into API error responses.
• The client translates API error values into typed client errors via
  errors.As.
• The CLI formats user-facing recovery guidance.

The daemon now returns structured change-conflict API errors when a workshop
action is blocked by a change conflict. The response includes the blocking
change ID, kind, status, project ID, and workshop name.

Example API error value:

{
  "kind": "change-conflict",
  "message": "workshop \"dev\" has \"refresh\" change in progress",
  "value": {
    "change-id": "29",
    "change-kind": "refresh",
    "change-status": "Wait",
    "project-id": "...",
    "workshop": "dev"
  }
}

The client exposes this through client.ChangeConflictError, allowing CLI
commands to inspect structured change details without parsing human-readable
daemon messages.

QA

Unit and package tests run:

go test ./client
go test ./cmd/workshop -check.f TestStopChangeConflict
go test ./internal/overlord/conflict
go test ./internal/overlord/workshopstate -check.f TestStopManyWaitingReturnsChangeConflict
go test ./internal/daemon -check.f TestStopWorkshopChangeConflict

End-to-end manual QA:

1. Created a local workshop with a project SDK hook that initially succeeds.
2. Launched the workshop.
3. Changed the SDK hook to fail.
4. Ran refresh with --wait-on-error.
5. Ran workshop stop while the refresh was paused.

Observed output:

error: cannot stop "refresh-output": refresh change is waiting on error
To view details: "workshop tasks 4"

To abort and undo the refresh: "workshop refresh --abort refresh-output"
Otherwise, resolve the error, then run "workshop refresh --continue refresh-output"
After that, run "workshop stop refresh-output" again.

The paused refresh was then cleaned up with:

workshop refresh --abort refresh-output

Self-review quick check

• Make decisions that cost a lot to reverse explicit in the PR description.
• Avoid nested conditions.
• Delete dead code and redundant comments.
• Normalise symmetries by sticking to doing identical things identically.
• Check that coupled code elements, files, and directories are adjacent. For example, test data is stored as close as possible to a test.
• Put variable declaration and initialisation together.
• Divide large expressions into digestable and self-explanatory ones. Use multiple variables if required.
• Put a blank line between two logically different chunks of code.
• Follow the style guide for new error messages.

Docs

Procedure:

• I have checked and added or updated relevant documentation.
• I have checked and added or updated relevant release notes.
• I have included the technical author in the review.

Content:

• Headings and titles accurately describe the content.
• New and updated pages include correct metadata.
• Documentation tests are added or updated where applicable (for tutorial/ and how-to/ sections).
• Documentation follows the style guide.
• If needed, docs/.coverage.yaml updated, coverage tags added (.. artefact).

---

Or:

• I confirm the PR has no implications for documentation.

[dmitry-lyfar]

@tlm thank you, I just noted, we don't use any commit message annotation. Just capital letter, preferably start with a verb.

[tlm]

@dmitry-lyfar ta, will update going forward.

[dmitry-lyfar]

There are unit tests and linter issues