`parseInt` calls without an explicit radix throughout `resolveCodeMemoryConfig`

[m-dmupba]

Bug

Every parseInt call in src/db/config.ts is missing the radix argument. Example block (lines 100–122):

condensedMinFanout: parseInt(env.CODEMEMORY_CONDENSED_MIN_FANOUT || "4"),
incrementalMaxDepth: parseInt(env.CODEMEMORY_INCREMENTAL_MAX_DEPTH || "1"),
leafChunkTokens: env.CODEMEMORY_LEAF_CHUNK_TOKENS ? parseInt(env.CODEMEMORY_LEAF_CHUNK_TOKENS) : undefined,
leafTargetTokens: parseInt(env.CODEMEMORY_LEAF_TARGET_TOKENS || "1200"),
// ...
compactionTokenThreshold: parseInt(env.CODEMEMORY_COMPACTION_TOKEN_THRESHOLD || "30000"),
compactionFreshTailCount: parseInt(env.CODEMEMORY_COMPACTION_FRESH_TAIL_COUNT || "20"),

Modern V8 treats 0-prefixed strings as base-10, so the famous octal landmine is gone, but the lint rule (radix) is on for a reason: any user who sets CODEMEMORY_COMPACTION_TOKEN_THRESHOLD=0x8000 or CODEMEMORY_LEAF_TARGET_TOKENS=1_200 (a perfectly valid JS numeric literal in their shell config script) will silently get a different number than expected — parseInt stops at the first non-digit and returns 0x8 and 1, respectively.

Reproduction

node -e 'console.log(parseInt("1_200"))'    # 1
node -e 'console.log(parseInt("0x8000"))'   # 32768  (parsed as hex automatically)
node -e 'console.log(parseInt("1_200", 10))' # 1 — but at least the radix is explicit

Also: there is no NaN guard. If a user types CODEMEMORY_COMPACTION_TOKEN_THRESHOLD=thirty-thousand, the config silently becomes NaN and downstream tokens >= threshold comparisons all return false, effectively turning compaction off without any log line.

Workaround

Always export numeric env vars as bare integers.

Suggested fix

A small parseIntStrict(env, default) helper that adds , 10 and falls back to the default on Number.isNaN(parsed), with a one-line warn via logStartupBannerOnce.