Feat/git repo output sync queue

[gatzjames]

Overview

Improves on the existing design of the repo-watcher with guarantees for data consistency and no race conditions when reading/writing to/from the db/fs.

Consistency

In order to achieve these guarantees we introduce a serial queue (not direction lock):

All sync work — both FS→DB and DB→FS — goes through one FIFO queue.
Tasks never run concurrently, eliminating all race conditions.
Throughput isn't a concern since sync events are infrequent.

No infinite loops

To ensure there are no write -> read -> write loops we use Content-hash dedup (not timing-based suppression):

After writing a YAML file to disk, record its SHA-256 hash.
When the watcher sees the file change, compare hashes — if it matches, skip (it's our own write).
This is writer-agnostic and handles external tools, git ops, and timing edge cases.

mtime as fast-path: Before computing content hash, we check the mtime first (cheap stat call). Only read + hash the file if mtime changed.

Other

• Removes the project-nedb-client and completely uses the new sync mechanism for all git operations which completely decouples the git functionality from the app data storage.
• The UI now refreshes when data on the repository (fs) change
• Added an open folder button and copy repo path in the Project Settings view

[aikido-pr-checks]

Potential file inclusion attack via reading file - high severity
If an attacker can control the input leading into the ReadFile function, they might be able to read sensitive files and launch further attacks with that information.

Show fix

Suggested change

	const diskFileSet = new Set(currentDiskFiles.map(f => path.normalize(f)));
	const base = path.resolve(this.repoDir);
	const diskFileSet = new Set(currentDiskFiles.map(f => {
	const target = path.resolve(f);
	const rel = path.relative(base, target);
	if (rel.startsWith('..') || path.isAbsolute(rel)) {
	throw new Error('Invalid file path');
	}
	return path.normalize(f);
	}));

_{More info}

[aikido-pr-checks]

Potential file inclusion attack via reading file - medium severity
If an attacker can control the input leading into the ReadFile function, they might be able to read sensitive files and launch further attacks with that information.

Show fix

Suggested change

	result.push(path.normalize(absPath));
	const resolvedBase = path.resolve(dir);
	const resolvedTarget = path.resolve(absPath);
	const relative = path.relative(resolvedBase, resolvedTarget);
	if (relative.startsWith('..') || path.isAbsolute(relative)) {
	continue;
	}
	result.push(resolvedTarget);

_{More info}

[aikido-pr-checks]

A timing attack might allow hackers to bruteforce passwords - low severity
An insecure way to compare passwords to user input might allow hackers to bruteforce passwords.

Show fix

Suggested change

	if (this.lastWrittenHash.get(absPath) === hash) {
	continue;
	}
	const lastHash = this.lastWrittenHash.get(absPath);
	if (lastHash) {
	const actual = crypto.createHash('sha256').update(hash).digest();
	const expected = crypto.createHash('sha256').update(lastHash).digest();
	if (crypto.timingSafeEqual(actual, expected)) {
	continue;
	}
	}

_{More info}