fix(channels): leftovers from #153 — stale lock-text write, '|' in cache keys, ignore corescope-ingestor

[dborup]

Summary

Three small leftovers found while fixing #152 in PR #153 (round 4, head dde4fc98). The PR left them alone because they were out of scope. None blocks #153.

Relates to #152, #153.

1. The "no decryption key" lock text can overwrite a newer request's view (P3)

Where: public/channels.js ~2530–2543 at dde4fc98 (selectChannel, the encrypted-channel branch). The same code is on master 727efca0 at ~2365.

Problem: for an encrypted channel, selectChannel walks the stored keys and awaits ChannelDecrypt.computeChannelHash once per key. When no key matches, it writes the #781 lock message ("This channel is encrypted and no decryption key is configured"). It does not check isStaleMessageRequest(request) before that write.

If the user selects another channel, or the region changes, while that loop is still awaiting, the lock text can land on top of the newer request's pane. This is the same late-write pattern that #153 fixed for "Decrypting messages…".

Fix: check isStaleMessageRequest(request) after the loop, and after each await where it matters, before writing to msgEl. Apply the same check to the other lock-text writes in that function if they follow an await.

Test: a unit test in the style of the R4-3 tests in test-channels-client-state-152.js:

1. Select encrypted channel A with several stored keys and slow computeChannelHash.
2. Select B before the loop finishes.
3. B's view must not be overwritten by the lock text.

The test must fail on the current code.

2. A | in a channel name can clear another channel's cache (theoretical)

Where: public/channel-decrypt.js: CACHE_REGION_SEP = '|' (~361), channelCacheKey (~363) and clearChannelCache (~504).

Problem: cache keys are <channel>|<sorted regions>, and removing a key clears <channel> plus every key that starts with <channel>|. Take two channels named #a and #a|b: removing #a also clears #a|b's cache, and #a|b's entries can be confused with a region-scoped entry of #a.

Today this costs at most a re-decrypt, and it does not leak plaintext. It is still worth making the key unambiguous.

Fix: use a separator that cannot appear in a channel name, or encode the channel part of the key, for example with encodeURIComponent. The one-time migration that #153 added can rewrite any existing keys.

Test: channels #a and #a|b, each with cached entries. Removing #a leaves #a|b's entries intact.

3. corescope-ingestor is not in .gitignore

Where: .gitignore lists corescope-server (~33) but not corescope-ingestor.

Problem: every local E2E build of the ingestor binary leaves an untracked file in the repo root, so agents have to delete it by hand before committing. That invites an accidental commit.

Fix: add corescope-ingestor next to corescope-server.

Acceptance criteria

• Item 1: a regression test that fails before the fix and passes after it.
• Item 2: a unit test as described above. Existing cache and migration tests stay green.
• Item 3: git status is clean after go build -o corescope-ingestor ./cmd/ingestor in the repo root.
• deploy.yml and its fork guards are unchanged.

[dborup]

Two more nits from the round-4 re-review of #153 (head dde4fc98)

Both come from Minimax's re-review (APPROVE with nits). Items 1 and 2 of this issue were confirmed there too: the lock-text overwrite reproduced 3/3 in Chromium on both head and master.

4. Dead code that still uses the old cache-key format (nit)

Where: public/channel-decrypt.js ~523 (cacheMessages) and ~530 (getCachedMessages), exported at ~581–582.

Problem: both functions still read and write keys without the |<regions> part. No production code calls them; the only references are in test-channel-decrypt-e2e.js and test-channels-client-state-152.js.

Fix: remove them and their exports. Update or drop those test references. If a caller is ever needed, it should go through channelCacheKey.

5. Plaintext from before #153 survives until the first cache use (nit)

Where: ensureCacheMigrated() in public/channel-decrypt.js (~418).

Problem: the one-time cleanup of pre-#153 cache keys is lazy. It runs on the first cache read or write after the upgrade, not when the page loads. Until then, decrypted plaintext under old-format keys stays in localStorage, even for a channel whose key was already removed before the upgrade.

The current call pattern makes this low-risk; Minimax's mutant M16 survives as equivalent.

Fix: call ensureCacheMigrated() once when ChannelDecrypt initialises, or when the channels page loads. Keep the lazy call as a fallback.

Test: seed old-format entries, load the module without touching the cache, and assert that the entries are gone.

[dborup]

Fixed by #166 (merged as 3fb1dc11).

• The encrypted-channel lock text checks for a stale request before it writes.
• The decrypt-cache keys no longer collide when a channel name contains |. The cache version was bumped, so the old cache is dropped once.
• corescope-ingestor is ignored as intended.