fix(security): path-traversal guards for chunkCache and fetch-chunk (CWE-22)

[jamubc]

Summary

Closes the CWE-22 path-traversal vector in the chunk cache subsystem.

• getChunks() — format validation (primary guard): adds a ^[a-f0-9]{8}$ regex check as the first statement. Any cacheKey that is not exactly 8 lowercase hex characters (i.e. a sha256 slice) is rejected immediately. This blocks ../, absolute paths, and other traversal payloads at the source, protecting every caller regardless of entry point.
• getChunks() — path containment (defense-in-depth): adds path.resolve + startsWith(CACHE_DIR + sep) to verify the resolved file path stays inside CACHE_DIR even after format validation passes.
• getChunks() — remove DELETE primitive: the catch block previously called fs.unlinkSync(filePath) on any parse error. With an unvalidated cacheKey this was a path-traversal-driven delete. The unlink is removed; the file is left in place on error.
• fetch-chunk.tool.ts — entry validation: adds the same ^[a-f0-9]{8}$ check at the tool boundary before calling getChunks().
• ask-qwen.tool.ts — entry validation: adds format validation on chunkCacheKey in the cache-continuation path, which previously bypassed the fetch-chunk check entirely.

Test Plan

• npm run lint (tsc --noEmit) passes clean
• Manual: valid 8-char hex key retrieves cached chunks as before
• Manual: keys such as ../../etc, /etc/passwd, abc are rejected with a clear error message

[gemini-code-assist]

Code Review

This pull request introduces input validation for cache keys across tools and utility functions, ensuring they conform to an 8-character hexadecimal format to prevent path traversal vulnerabilities. It also adds a defense-in-depth path containment check in the chunk cache utility and removes the automatic file deletion on read errors to mitigate potential path-traversal deletion risks. The review feedback suggests a more robust and platform-independent way to perform the path containment check using path.relative instead of string concatenation.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Using string concatenation (path.resolve(CACHE_DIR) + path.sep) for path containment checks can be fragile and may fail on certain platforms or edge cases (for example, if CACHE_DIR resolves to a root directory like / or C:\).

A more robust and standard way to verify that a resolved path remains within a target directory in Node.js is to use path.relative and check if the result starts with .. or is absolute.

Suggested change

	const resolved = path.resolve(filePath);
	if (!resolved.startsWith(path.resolve(CACHE_DIR) + path.sep)) {
	Logger.debug(`Rejected cacheKey escaping CACHE_DIR: ${cacheKey}`);
	return null;
	}
	const relative = path.relative(CACHE_DIR, filePath);
	if (!relative || relative.startsWith('..') || path.isAbsolute(relative)) {
	Logger.debug(`Rejected cacheKey escaping CACHE_DIR: ${cacheKey}`);
	return null;
	}