IFTTT trigger sends its webhook with no request timeout

[scttbnsn]

app/triggers/providers/ifttt/Ifttt.ts:84 calls axios(options) with no timeout, so an unresponsive maker.ifttt.com hangs the notification until Node's socket default gives up.

Its nine axios-calling siblings (Apprise, Discord, Google Chat, Matrix, Mattermost, ntfy, Rocket.Chat, Teams, Telegram) all pass getOutboundHttpTimeoutMs() from app/configuration/runtime-defaults.js. IFTTT is the only one that doesn't.

Not an SSRF issue: the URL is the fixed maker.ifttt.com endpoint, not operator-supplied. It's a liveness gap, and it's the reason SECURITY-ASSURANCE.md has to carry a 'no' in the timeout column for this one path.

Fix: import getOutboundHttpTimeoutMs and add timeout: getOutboundHttpTimeoutMs(), to the options object. Ifttt.test.ts has six expect(axios).toHaveBeenCalledWith({...}) assertions that pin the exact options shape, so all six need the new key. Then flip the IFTTT row in SECURITY-ASSURANCE.md to 'yes' and drop the sentence pointing at this issue.

Found by CodeRabbit while reviewing #702. Kept out of that PR to keep a docs forward-port from growing a code change.

[scttbnsn]

Fixed on dev/v1.7 in #707. IFTTT now passes getOutboundHttpTimeoutMs() like its nine sibling providers, the six exact toHaveBeenCalledWith assertions carry the new key, and SECURITY-ASSURANCE.md's outbound-controls table reads yes for the IFTTT timeout column.

Closing by hand because the Fixes: footer only auto-closes on a merge to the default branch, and this landed on the dev branch. It ships with v1.7.0.