Re-request (narrowed): name the user-controlled recovery path in create_goal's 'active goal exists' error

Summary

This is a narrowed re-request of #23365 (closed as not-planned), reworked to address both objections raised in the maintainer review there:

1. "Tool definitions consume tokens" — this request adds nothing to any tool definition. It asks for a one-line change to a runtime error string, which is only emitted when the call already fails, so the standing token cost is exactly zero.
2. "No multiple ways to expose the same command" — this request adds no command, alias, or new tool surface. The goal lifecycle stays exactly as it is.

Problem

When the model calls create_goal while the thread already has an active goal, the call correctly fails (good safety boundary — goal replacement must stay user-controlled). The current error text is:

cannot create a new goal because this thread has an active goal; complete the active goal first

This tells the model the only recovery is to complete the existing goal. In practice, when a user asks in natural language to "set a new goal", the old goal is often something they want to abandon, not complete. The model then either:

• marks the user's still-wanted goal complete just to make room (unsafe pressure on a user-owned state), or
• reports failure without being able to name the actual user action that unblocks it.

The model has no way to know that the intended recovery is the user running /goal clear (or choosing to keep the old goal), because the error text never mentions that path.

Requested change

Extend the create_goal failure message so the recovery path is explicit, e.g.:

cannot create a new goal because this thread has an active goal; the user can clear or replace it explicitly (/goal clear), or the active goal can be completed first — do not clear it yourself

Properties of this fix:

• Zero standing token cost (error string, not tool schema).
• No new command surface.
• Strengthens the original safety boundary instead of weakening it: the model is explicitly told clearing is the user's call, reducing the incentive to force-complete goals it shouldn't touch.

Happy to prepare the patch (one line + test) on a fork branch if a maintainer confirms the wording direction is acceptable, since PRs to this repo are staff-only.