feat: in-memory LRU email body cache

[mavonx]

What?

Replaces the disk-only email body cache with an in-memory LRU cache backed by write-through disk persistence.

• Single global LRU instance shared across all folders via sync.Once singleton.
• Fast Get() and Put() operations — O(1) via hashmap + doubly-linked list.
• Write-through: every Get() and Put() immediately persists to disk, so no data is lost on crash.
• Eviction removes least-recently-used entries from both memory and disk atomically.
• On the first GetLRUInstance() call, LoadFromDisk() restores LRU order using LastAccessedAt timestamps sorted oldest-first, so the most recently accessed email ends up at the front.

Why?

The previous disk-only approach had two bottlenecks: GetCachedEmailBody() read the entire folder JSON file on every call, and pruneEmailBodyCacheSize() loaded all folder files on every SaveEmailBody() call. With multiple accounts and many folders, this becomes expensive.

Related #1171

[andrinoff]

@mavonx tests fail

[mavonx]

@andrinoff

I will double-check this again tonight.

[andrinoff]

we use log.Printf

[andrinoff]

@andrinoff

Fine, I’m just busy right now. When I get back home, I’ll fix those issues and then commit the changes.

Yeah, no worries, I'm just trying to triage as many PRs as I can, i'm very busy

[mavonx]

@andrinoff

I’ll check why the tests are failing tonight, but I’ve already addressed your RCs.

[mavonx]

@andrinoff

I think we're ready now.

[andrinoff]

The LRU struct has no sync.Mutex or sync.RWMutex. Every method — Get, Put, Delete, evict, and now the threshold update in GetLRUInstance — touches lru.cache, lru.ll, and lru.currentSize without any lock.

After it, i'll merge. This could be critical in case of a race

[andrinoff]

lgtm