OperationFailedError loses structured operation and reason data

[astrobot-houston]

Originally reported by @hiro-nikaitou in #440.

All community-submitted pull requests are automatically converted to issues (bugs) & discussions (feature requests, enhancements) where they can be triaged and prioritized. Once prioritized, a PR implementation is created automatically.

Describe the Bug

OperationFailedError in packages/runtime/src/errors.ts hardcodes its details field to an empty string ('') and omits meta entirely. When a dispatched operation fails, the serialized error contains no structured data — the operation name and underlying failure reason are only embedded in the prose message string.

This means downstream error trackers must regex-parse the message to recover the operation name and reason. Because the message includes a unique dispatch UUID, every occurrence appears as a distinct error, breaking issue grouping and preventing programmatic classification.

Expected Behavior

OperationFailedError should populate details with the failure reason and include { operation, reason } in meta, matching the pattern used by other FlueError subclasses (e.g. CloudflareAIBindingError, AttachmentLoadingError). This allows consumers to inspect structured fields via instanceof checks and structured data rather than parsing message text.

Steps to Reproduce

1. Trigger a dispatched operation that fails (e.g., dispatch an agent input that results in an error).
2. Catch the resulting OperationFailedError.
3. Inspect the error's details and meta fields — details is an empty string and meta is undefined, despite the operation name and reason being available at construction time.

---

Original implementation from #440 by @hiro-nikaitou

[FredKSchott]

Duplicate of #431 — tracking there.