Clean up FileStorage resource leaks and legacy utils.js concurrency

[bjcoombs]

Summary

Follow-up to #1568. The core modifyJson() pattern adoption is complete, but two cleanup items remain.

Remaining Work

1. FileStorage.close() not being called

apps/cli/src/commands/export.command.ts instantiates FileStorage 9 times but never calls .close(), causing the Writer cache to grow unbounded.

Affected locations:

• Lines where new FileStorage(...) is called without corresponding cleanup

Fix: Wrap FileStorage usage in try/finally to ensure close() is called, or refactor to use a shared instance that's properly managed.

2. Legacy utils.js read-outside-lock pattern

scripts/modules/utils.js writeJSON() function still receives data from outside the lock:

function writeJSON(filepath, data, projectRoot = null, tag = null) {
    // 'data' was read OUTSIDE the lock by the caller
    withFileLockSync(filepath, () => {
        let finalData = data;
        // ...
    });
}

While it does re-read inside the lock for tag merging scenarios, the initial data parameter still comes from a potentially stale read.

Options:

1. Migrate callers to use the TypeScript modifyJson() pattern
2. Add a modifyJSON() function to utils.js that takes a modifier callback
3. Document as acceptable risk if legacy code is being phased out

References

• Issue Adopt modifyJson() pattern for read-modify-write operations to prevent lost updates #1568: Original modifyJson adoption issue
• PR fix: Add cross-process file locking to prevent race conditions #1566: Initial file locking fix