#23621: fix(LINE): keep startAccount promise alive to prevent auto-restart loop

## Summary Fixes a channel stability issue where the LINE provider enters an exponential-backoff restart loop immediately after starting, making LINE completely unusable. The gateway channel framework expects `startAccount` to return a long-lived Promise (resolved only on shutdown). LINE's webhook-based `monitorLineProvider` resolved immediately after registering the HTTP route, causing the gateway to interpret it as "provider exited" and trigger auto-restart — up to 10 attempts with increasing delays. This aligns with the project's current **Stability** focus on fixing edge cases in channel connections. Closes #20573 Closes #21908 Closes #21892 ## Root Cause `monitorLineProvider()` registers the webhook HTTP route and resolves right away (~4ms). The gateway's `.finally()` → `.then()` chain treats a resolved Promise as "provider stopped" and starts exponential-backoff restarts. Telegram avoids this because its polling loop naturally blocks. LINE's webhook mode had no equivalent blocking mechanism. ## Changes - **`extensions/line/src/channel.ts`**: After `await`ing `monitorLineProvider`, add a `Promise` that waits for `ctx.abortSignal`'s `abort` event, keeping the provider alive until gateway shutdown. - **`extensions/line/src/channel.startup.test.ts`**: Update the test to use an `AbortController` so it can verify the new blocking behavior. ## Test Plan - [x] `pnpm vitest run --config vitest.extensions.config.ts extensions/line/` — all tests pass - [x] Deployed and verified: LINE provider starts without auto-restart loop and messages are delivered successfully ## AI Disclosure - [x] AI-assisted (Claude Code) - [x] Degree of testing: **fully tested** — unit tests pass, deployed and verified in production - [x] Prompt used below - [x] I understand what the code does: `startAccount` previously returned as soon as `monitorLineProvider` resolved. The fix adds an `await` on a `Promise` gated by `abortSignal`, so the function stays pending until the gateway explicitly signals shutdown. The test was updated to drive the `AbortController` so the new blocking path is exercised. <details> <summary>Prompt</summary> LINE provider does not work. It keeps auto-restart attempts, and here are the logs. ``` 2026-02-21T16:28:49.550705335Z [inf] 2026-02-21T16:28:46.085Z [line] [default] starting LINE provider (BOT_DISPLAY_NAME) 2026-02-21T16:28:49.550709976Z [inf] 2026-02-21T16:28:46.087Z [line] [default] auto-restart attempt 1/10 in 5s ... 2026-02-21T16:31:36.788836053Z [inf] 2026-02-21T16:31:32.905Z [line] [default] auto-restart attempt 6/10 in 174s ``` I have checked that the auth token is correct. (FYI: https://developers.line.biz/en/reference/messaging-api/#get-bot-info) - Compare with how other channels are implemented and create an implementation plan. - Prioritize fixing this error. No need for a big architecture improvement. </details> <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR fixes a critical bug where the LINE provider enters an exponential-backoff restart loop immediately after starting. The root cause was that `monitorLineProvider` returns a resolved Promise immediately after registering the webhook (unlike polling-based providers like Telegram that block until shutdown). The gateway interprets a resolved Promise as "provider stopped" and triggers auto-restart. The fix adds a blocking `await` on a Promise gated by `ctx.abortSignal`, keeping `startAccount` pending until shutdown. This matches the established pattern used by other webhook-based channels like Slack (see `src/slack/monitor/provider.ts:355-359`). The test was properly updated to drive the `AbortController` so the new blocking behavior is exercised. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The fix follows an established pattern used by other webhook-based channels (Slack), addresses a critical usability bug with a minimal, surgical change, includes proper test coverage, and has been deployed and verified in production according to the PR description - No files require special attention _{Last reviewed commit: 6469ad9} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->