chore(daemon): named timeout constants

[mvanhorn]

What?

Replaces ad-hoc 60*time.Second and 30*time.Second literals in daemon/handler.go with two named constants and a brief comment documenting the split, exactly as suggested in the issue body.

const (
    fetchTimeout  = 60 * time.Second
    mutateTimeout = 30 * time.Second
)

fetchTimeout (was 60*time.Second):

• handleFetchEmails (line 129)
• handleFetchEmailBody (line 154)
• async fetch inside handleMarkRead (line 318)

mutateTimeout (was 30*time.Second):

• handleDeleteEmails (line 193)
• handleArchiveEmails (line 216)
• handleMoveEmails (line 239)
• handleMarkRead (line 262)
• handleFetchFolders (line 287)

Why?

fetchTimeout covers reads against the upstream IMAP provider, which can return large bodies and so are given more headroom. mutateTimeout covers state-changing operations and folder listings, which are bounded by IMAP command latency rather than payload size.

If the maintainer wants handleFetchFolders reclassified to fetchTimeout (which would be a behavior change from 30s to 60s), happy to do that as a follow-up — kept it at the existing value here to keep this purely a refactor.

Closes #985.

[floatpanebot]

Hi @mvanhorn! Please fix the following issues with your PR:

• Title: Is too long (51 characters). The PR title must be strictly under 40 characters.
• Body: Missing the ## What? or ## Why? headings required by the PR template.

[LeaWhoCodes]

@mvanhorn follow the format, please

Formatting issues have been resolved. Thank you!

[andrinoff]

lgtm

[mvanhorn]

Cheers for merging this @andrinoff, thanks. Replacing the bare 60s and 30s literals with fetchTimeout and mutateTimeout makes the split self-documenting wherever someone reads handler.go.

[mvanhorn]

Appreciate the quick turnaround @andrinoff. Naming fetchTimeout and mutateTimeout makes the daemon handler intent obvious at the callsite.