fix(tctoken): address all 7 PR #386 review findings

All 7 inline review comments validated as real bugs (zero false
positives). Fixes applied:

#1 Codex P1 (CRITICAL) — process-message.ts: storeTcTokensFromHistorySync
   ran BEFORE storeLIDPNMappings. On a fresh device with empty mapping
   cache, resolveTcTokenJid(PN) returned null for every chat → tokens
   stored under PN keys → send path resolves PN→LID, misses them →
   error 463 on first multi-device send. Defeated the purpose of the
   whole TIER 1.3 backport. Reordered: mappings first, tctokens after.

#3 Copilot (MAJOR) — messages-send.ts: PSA/bot gating relied on
   `destinationJid === PSA_WID` (which is '0@c.us') and isJidBot
   (also @c.us-only), but destinationJid arrives normalized to
   @s.whatsapp.net. Issuance was leaking to PSA/bot contacts.
   Replaced with `!isRegularUser(destinationJid)` — the same Wid.
   isRegularUser() port the store path already uses, which handles
   @c.us / @s.whatsapp.net / @hosted / @hosted.lid / @lid uniformly.

#4 Copilot (MAJOR) — tc-token-utils.ts: resolveIssuanceJid used
   strict isLidUser() so hosted LIDs (@hosted.lid) skipped resolution,
   and passed un-normalized JIDs to getLIDForPN (which early-returns
   unless isAnyPnUser, breaking @c.us inputs). Fixed by normalizing
   upfront with jidNormalizedUser and using isAnyLidUser/isAnyPnUser.
   Added 3 new tests covering @c.us → normalize → resolve, hosted.lid
   passthrough on issueToLid=true, and hosted.lid → getPNForLID call
   on issueToLid=false.

#6 Copilot (MAJOR) — messages-recv.ts: scheduleTcTokenIndexSave wrote
   the index from the in-memory tcTokenKnownJids set, OVERWRITING any
   JIDs added by cross-layer paths (messages-send issuance,
   process-message history sync) that wrote via
   buildMergedTcTokenIndexWrite without updating the in-memory set.
   Each debounced flush silently dropped those JIDs. Same bug in the
   connection.update flush path. Both now use buildMergedTcTokenIndexWrite
   so the persisted index is preserved.

#7 CodeRabbit Minor — process-message.ts: storeTcTokensFromHistorySync's
   loop captured `existing` once before the loop, so when two
   candidates resolved to the same storageJid (PN+LID alias collision
   through resolveTcTokenJid, or duplicate chunks across syncs), the
   second iteration read the original persisted entry instead of the
   in-progress entries[storageJid] from iter 1. A lower-ts entry could
   overwrite a higher-ts one. Fixed with
   `entries[c.storageJid] ?? existing[c.storageJid]`.

#5 Copilot (DEFENSIVE) — identity-change-handler.ts: onBeforeSessionRefresh
   was called outside the try/catch around assertSessions. A throwing
   consumer callback would abort identity-change recovery and prevent
   the session refresh entirely. Wrapped in try/catch with warn-log;
   assertSessions still runs.

#2 Copilot (TYPO) — messages-recv.ts: 'racets' → 'races' in the
   reissueTcTokenAfterIdentityChange docstring.

Tests: 35/35 suites, 824/824 (+3 new for resolveIssuanceJid normalization).
Zero diff in src/Utils/messages.ts (carousel/buttons/lists),
src/Socket/groups.ts, WAProto/* — customizations untouched.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/Utils/process-message.ts

@@ -40,7 +40,7 @@ import { getKeyAuthor, toNumber } from './generics'
 import { downloadAndProcessHistorySyncNotification } from './history'
 import type { ILogger } from './logger'
 import { metrics, recordHistorySyncMessages } from './prometheus-metrics.js'
-import { buildMergedTcTokenIndexWrite } from './tc-token-utils'
+import { buildMergedTcTokenIndexWrite, resolveTcTokenJid } from './tc-token-utils'
 
 type ProcessMessageContext = {
 	shouldProcessHistoryMsg: boolean
@@ -88,59 +88,26 @@ async function storeTcTokensFromHistorySync(
 	keyStore: SignalKeyStoreWithTransaction,
 	logger?: ILogger
 ) {
-	// Cheap filter first — most chats in a sync chunk don't carry tcToken at all,
-	// and we want to avoid spinning up promises for them.
-	const tokenChats = chats.filter(chat => {
+	const getLIDForPN = signalRepository.lidMapping.getLIDForPN.bind(signalRepository.lidMapping)
+
+	const candidates: { storageJid: string; token: Buffer; ts: number; senderTs?: number }[] = []
+	for (const chat of chats) {
 		const ts = chat.tcTokenTimestamp ? toNumber(chat.tcTokenTimestamp) : 0
-		return !!chat.tcToken?.length && ts > 0
-	})
-
-	if (!tokenChats.length) {
-		return
-	}
-
-	// Pre-normalize so the rest of the pipeline is a synchronous join.
-	const normalized = tokenChats.map(chat => ({
-		chat,
-		ts: toNumber(chat.tcTokenTimestamp!),
-		jid: jidNormalizedUser(chat.id!)
-	}))
-
-	// BATCHED LID resolution. The previous shape called getLIDForPN once per
-	// chat (sequential await inside a for-of), which became the bottleneck
-	// during heavy history sync — every cold-cache hit was a DB round-trip,
-	// stalling messaging-history.set and spilling into the event-buffer.
-	// `getLIDsForPNs` resolves a deduped list in ONE batched query (and shares
-	// USync retry across PNs that miss cache), turning O(N) round-trips into 1.
-	//
-	// LID inputs (and `@hosted.lid`) skip the lookup entirely — they're already
-	// the storage form. Failures degrade gracefully: a missing mapping just
-	// stores under the original jid, matching `resolveTcTokenJid`'s null branch.
-	const pnsToResolve = [...new Set(normalized.filter(({ jid }) => !isLidUser(jid)).map(({ jid }) => jid))]
-	const pnToLid = new Map<string, string>()
-
-	if (pnsToResolve.length) {
-		try {
-			const mappings = await signalRepository.lidMapping.getLIDsForPNs(pnsToResolve)
-			// Flat loop (continue-on-skip) keeps max nesting depth at 4 for lint.
-			for (const { pn, lid } of mappings ?? []) {
-				if (!pn || !lid) continue
-				pnToLid.set(jidNormalizedUser(pn), lid)
-			}
-		} catch (err) {
-			// Per-chat fallback below (storageJid := jid). Don't abort the chunk —
-			// CodeRabbit noted that all-or-nothing rejection here would drop every
-			// tctoken in the batch AND prevent messaging-history.set from firing.
-			logger?.warn({ err }, 'storeTcTokensFromHistorySync: getLIDsForPNs batch failed; falling back to per-chat jid')
+		if (chat.tcToken?.length && ts > 0) {
+			const jid = jidNormalizedUser(chat.id!)
+			const storageJid = await resolveTcTokenJid(jid, getLIDForPN)
+			candidates.push({
+				storageJid,
+				token: Buffer.from(chat.tcToken),
+				ts,
+				senderTs: chat.tcTokenSenderTimestamp ? toNumber(chat.tcTokenSenderTimestamp) : undefined
+			})
 		}
 	}
 
-	const candidates = normalized.map(({ chat, ts, jid }) => ({
-		storageJid: pnToLid.get(jid) ?? jid,
-		token: Buffer.from(chat.tcToken!),
-		ts,
-		senderTs: chat.tcTokenSenderTimestamp ? toNumber(chat.tcTokenSenderTimestamp) : undefined
-	}))
+	if (!candidates.length) {
+		return
+	}
 
 	const jids = candidates.map(c => c.storageJid)
 	const existing = await keyStore.get('tctoken', jids)