fix(file-store): add write lock to prevent concurrent save race condition

[matagaralph]

The FileTokenStore had a race condition where concurrent saveToken or deleteToken calls could interleave their read-mutate-write cycles, causing one write to clobber another.

Fixed by introducing a promise-based write lock via withLock, which serializes all mutating operations without any external dependencies. Read operations are unaffected.

Also tightened up findToken in both FileTokenStore and RedisTokenStore to check expiresAt and return null for expired tokens rather than leaking stale data to the OAuth layer.

[Copilot]

Pull request overview

Adds an in-process write serialization mechanism to FileTokenStore to mitigate concurrent saveToken / deleteToken races when persisting tokens to disk.

Changes:

• Introduce a writeLock promise chain in FileTokenStore.
• Add a withLock() helper and wrap saveToken() / deleteToken() operations with it.

[Copilot]

The new write lock only serializes save/delete, but findToken still reads the file concurrently with writeFile. Since writeFile truncates and rewrites the JSON, a concurrent read can observe partial contents and JSON.parse will throw. Consider either (a) using the same lock for findToken/read operations, or (b) making writes atomic (write to a temp file and rename) so reads are always valid JSON.

Suggested change

	const tokens = await this.read();
	return tokens.find((t) => t.clientId === clientId && t.orgId === orgId) ?? null;
	return this.withLock(async () => {
	const tokens = await this.read();
	return tokens.find((t) => t.clientId === clientId && t.orgId === orgId) ?? null;
	});