Let a host start and observe a clip generation

[dazzatronus]

Generation could only be started from the SDK's own toolbar, and only its own overlay could see
the result. An application embedding Studio with custom UI, a batch action or a test harness
could do neither. Clip capture — the same shape of per-clip async operation — was already public
on both counts.

generateClip(clipId) starts a generation for a prompt-bearing clip. The three
clip:generation* events move onto the public event map beside the capture events, so a host can
subscribe through edit.events.

No behaviour changes. The event strings are unchanged, the method body is untouched, and the
transient generation state stays out of the edit document as before.

One thing the docstring now states that a host needs: removing the clip, reloading the edit or
disposing it leaves the generation with no completed or failed event after its started. Anything
tracking progress from events alone has to handle that.

Verify: npm run verify:ci — lint, typecheck, coverage (2053 tests), build, package contract.
tests/generation-public-api.test.ts drives the SDK only through public API and fails all three
cases if generateClip is stubbed out.

[github-actions]

🎉 This PR is included in version 2.19.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀