Bound native group keys and channels

[highesttt]

LTSM has a fixed 16 MiB heap. A session still keeps the native key and channels of every group key it unwraps, and nothing ever destroys them. A session that sees enough distinct group keys exhausts the heap and aborts with ltsm: WASM abort called.

This keeps at most 4096 native group keys and channels (about 3 MB) and evicts the least recently used. Eviction destroys the native key and every channel created from it through the new Runner.KeyDestroy. The connector already fetches and unwraps a missing group key on demand (fetchAndUnwrapGroupKey on a decrypt miss and before every send), so an evicted key is reloaded the next time it is needed.

DecryptGroupMessage and EncryptGroupMessageRaw now hold Manager.mu from the key lookup through the native call, so an eviction cannot destroy the channel they are using. Native calls already serialize on the runner's own mutex. The ZIP retry in sendMessage now refetches the group key and retries once, like the main send path, and surfaces refetch failures the same way, because a key can be evicted between the two sends.

This relies on #252 (merged): before it, native unwrap leaked about 0.74 KB per call even after the key was destroyed, so eviction could not bound the heap.

#253 and #254 also change Runner and Manager, so whichever of them and this lands second needs a small rebase. In particular KeyDestroy has to follow #253's failure and discard handling.

Testing

Local, synthetic keys and messages only. No tests are added to the diff; the checks below ran outside the repo through a Go overlay. Each loop iteration unwraps a group key, then encrypts and decrypts a message and checks the plaintext.

Source	Same group key, 20,000 iterations	New group key every iteration
main with #250-#252	heap flat	aborts at iteration 6455
this PR	heap flat	20,000 iterations, 2051 keys and 2050 channels retained, heap flat at 11.08 MB

go test ./pkg/... and go test -race ./pkg/e2ee ./pkg/connector/... pass. A separate stress run with the cap lowered to 6 has four goroutines unwrap, encrypt and decrypt while keys are evicted. It sees only "key not loaded" or "not found" errors, passes three times under -race, and fails with unknown channel against a version of manager.go that released the lock before the native call.

Limits

• Not run against a live account. The synthetic loop covers the allocation path, not how many distinct group keys real accounts reach.
• The cap counts objects, not bytes. The channel to each group key's creator is cached once per creator and is not counted.
• Each eviction marks the crypto copy dirty, so the next channel operation refreshes the 16 MiB copy. This is a small cost per new group key once the cap is reached.
• Group encrypt and decrypt now hold Manager.mu for the duration of the native call, so other Manager methods wait behind them.

[indent]

Issues

All clear! No issues remaining. 🎉

3 issues already resolved

• Still present after the rebase. DecryptGroupMessage (line 658) and EncryptGroupMessageRaw (line 753) release m.mu after ensureGroupChannel, so a concurrent eviction can destroy the channel and the call fails once with unknown channel. It is not memory-unsafe and recovers after a key refetch. (fixed by commit 1868051)
  _{Found by Indent Review Agent}
• When LINE rejects a file with "Extension does not support file upload", sendMessage in pkg/connector/send_message.go (~line 749) zips, re-uploads and calls E2EEncryptGroupMessageRaw without fetchAndUnwrapGroupKey or a retry. If the key was evicted during the first send and zip upload, the send fails with "group key not loaded". Before this PR a loaded key never disappeared. (fixed by commit 1868051)
  _{Found by Indent Review Agent}
• The new ZIP retry in send_message.go ignores the error from fetchAndUnwrapGroupKey. If the refetch fails, the user gets a generic "failed to encrypt zipped file message: group key not loaded" instead of the ErrAbort or reconnect-required status the main send path returns. (fixed by commit 004cd1a)
  _{Found by Indent Review Agent at dc51cc6}

CI Checks

All CI checks passed on 004cd1a.

Review agents

Select any unchecked box below to run or rerun that agent.

Passed (1)

• Indent Review Agent · ZIP-retry fetch errors now match the main send path; no issues remain at this head.

Full results

Indent Review Agent

• Summary: ZIP-retry fetch errors now match the main send path; no issues remain at this head.
• Last ran on commit: 004cd1a3
• Latest result

  {
    "summary": "ZIP-retry fetch errors now match the main send path; no issues remain at this head.",
    "findings": []
  }