#6576: fix(signal): increase attachment fetch timeout to 60s

## Problem The default RPC timeout of 10 seconds is insufficient for larger audio attachments which need to be transferred as base64. This causes voice messages over ~15 seconds to timeout and show as `<media:unknown>`. ## Solution - Add `DEFAULT_ATTACHMENT_TIMEOUT_MS` (60s) in `client.ts` - Pass timeout to `signalRpcRequest` in `fetchAttachment()` - Keep general RPC timeout at 10s for other operations ## Testing Tested with 40-second voice messages on Signal which previously failed to process. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR introduces a dedicated 60s timeout for Signal attachment downloads (base64 over JSON-RPC) while keeping the default RPC timeout at 10s. It does this by exporting `DEFAULT_ATTACHMENT_TIMEOUT_MS` from `src/signal/client.ts` and using it in `fetchAttachment()` in `src/signal/monitor.ts` via the `timeoutMs` option passed to `signalRpcRequest`. The change is narrowly scoped to attachment fetching: other RPC calls still use the existing `DEFAULT_TIMEOUT_MS` fallback inside `signalRpcRequest`, so typical operations remain fast-failing while large voice notes have more time to transfer. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge and is a targeted change with low blast radius. - The change is small and isolated to Signal attachment fetching by threading an explicit timeout option through an existing RPC helper; it should not affect other RPC calls. Main remaining uncertainty is whether exporting the constant from `client.ts` matches the project’s intended API surface (vs keeping it internal or colocating the constant near attachment code). - src/signal/client.ts (export surface), src/signal/monitor.ts (attachment RPC options) <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->