Expose thread lifecycle events as plugin automation triggers

[SawyerHood]

Summary

Enable BB thread lifecycle events to trigger plugin API automations.

Context

We want plugin authors to be able to react to thread lifecycle state changes, for example:

• thread.success — run automation when a thread completes successfully
• thread.error — run automation when a thread fails/errors
• thread.end or equivalent terminal event — run generic cleanup/follow-up automation

There was also interest in exposing earlier lifecycle events such as preparing/provisioning and started/active so integrations can update remote task systems when work kicks off, not just when it finishes.

Desired behavior

• The new plugin API should expose thread lifecycle events as automation triggers.
• Include terminal events (success, error, maybe generic end) and consider enabling all meaningful lifecycle transitions (preparing, started, etc.).
• Event payloads should include enough context for integrations to update external systems: thread id/title/status, project id, provider/runtime status, error/success metadata if available, and links/identifiers where applicable.
• Avoid duplicate or noisy trigger behavior when status updates are repeated without a real transition.

Notes

Sawyer said the plumbing is already in place and this should be a capability for the new plugin API.