feat: support scrollToBottom in useSendFollowUpMessage

[Jean-crack]

Summary

• add optional scrollToBottom support to useSendFollowUpMessage
• thread the option through the shared bridge types and Apps SDK adaptor
• keep the MCP app adaptor API-compatible by accepting and ignoring the option there
• document the new hook signature and add targeted tests

Changes

• add SendFollowUpMessageOptions with scrollToBottom?: boolean
• update Adaptor.sendFollowUpMessage(prompt, options?)
• update Apps SDK types so window.openai.sendFollowUpMessage can receive scrollToBottom
• update useSendFollowUpMessage to accept optional options
• add hook runtime/type tests
• update API docs examples

Testing

• pnpm exec vitest run src/web/hooks/use-send-follow-up-message.test.ts
• pnpm --filter skybridge test:type
• pnpm --filter skybridge test:format

Notes

• The repo advertises Node 24.x, while this machine is currently on Node 22.22.1.
• The targeted checks above passed locally on this change set.

Fixes #512

[rodincave]

did you run it locally @Jean-crack ?

[Jean-crack]

Yes — I ran the targeted checks locally before opening this.

Passing locally:

• pnpm exec vitest run src/web/hooks/use-send-follow-up-message.test.ts
• pnpm --filter skybridge test:type
• pnpm --filter skybridge test:format
• pnpm --filter create-skybridge test:unit just passed again locally now

The failing CI job looks unrelated to this PR: packages/create-skybridge/src/index.test.ts timed out in the template-copy/download tests, so I've rerun the failed job.

[rodincave]

@Jean-crack CI fails

[Jean-crack]

Investigated this:

• I reran the failed Unit Tests job, and it passed on rerun: https://github.com/alpic-ai/skybridge/actions/runs/23599579689/job/68788948283
• I also reproduced the PR head locally on Node 24.14.1 (matching .nvmrc / CI), and pnpm run test:unit passed there too

So this looks flaky rather than caused by the actual useSendFollowUpMessage change.

Most suspicious spots in packages/create-skybridge/src/index.test.ts:

1. the should download template from repo test hits downloadTemplate(...) against github:alpic-ai/skybridge/examples/ecom-carousel, so the unit test depends on live network / remote fetch timing
2. both tests have un-awaited rejection assertions (expect(...).rejects.toThrowError()), and Vitest is already warning about that

I’d suggest:

• fixing those assertions to await expect(...).rejects...
• and, ideally, rewriting the repo-download test so it doesn’t rely on the network in CI