perf(@angular/build): batch last_accessed updates in sqlite cache store

[alan-agius4]

Previously, every get() call on SqliteCacheStore immediately executed an UPDATE statement to refresh the last_accessed timestamp for the requested cache key. In SQLite WAL mode, each unbatched UPDATE starts an implicit write transaction, acquiring exclusive write locks on the WAL and causing repeated disk I/O and fsync operations during cache reads.

During parallel builds, this serialized concurrent read operations and introduced unnecessary overhead on hot read paths.

To resolve this:

• last_accessed updates are buffered in an in-memory Set and flushed inside a single explicit transaction (BEGIN TRANSACTION; ... COMMIT;), periodically debounced (every 500ms or when batch reaches 100 entries) and before pruning on close().
• Flushes on close() ensure that recently accessed items have their timestamps persisted prior to TTL and LRU size pruning.
• SQLite PRAGMAs (busy_timeout = 5000, temp_store = MEMORY, mmap_size = 268435456) are tuned to reduce lock contention and leverage memory-mapped I/O.
• The debounced timer uses unref() to ensure it does not hold the Node.js process event loop open.

[gemini-code-assist]

Code Review

This pull request optimizes the SqliteCacheStore by batching SQLite access updates in a transaction instead of executing them individually on every cache hit. It also configures performance-related SQLite PRAGMAs and ensures pending updates are flushed upon closing. The review feedback suggests using BEGIN IMMEDIATE TRANSACTION; instead of BEGIN TRANSACTION; to prevent potential SQLITE_BUSY errors or deadlocks in concurrent environments.

[alan-agius4]

This PR was merged into the repository. The changes were merged into the following branches:

• main: a55a6b7
• 22.1.x: 22cce75