[Sycun]

Parallel create_asset calls can fail immediately with database is locked because deferred read-modify-write transactions cannot upgrade their read snapshots to a writer. Start SQLite transactions with _txlock=immediate so competing writers wait before taking a snapshot, using the shared DSN for both application and knowledge databases.

This builds on @OrdinarySF’s #329 and preserves the original authored commit. It retains the proposed 8/4 connection pool and 30-second busy timeout, but removes the outer eight-attempt retry: a persistent lock could otherwise cause roughly four minutes of waiting. SQLite handles the lock wait directly.

Regression coverage now starts 32 workers together and verifies distinct inserts, same-target deduplication and returned IDs, mixed creates/updates, and persisted counts. Both database constructors are also checked for writer reservation at Begin, concurrent WAL reads, and recovery after a competing writer releases its lock.

Validation:

• Reproduced immediate lock errors on upstream main before applying the fix.
• go test -race ./internal/database -count=1
• go test ./internal/database -run 'TestUpsertAssetsConcurrent|TestAssetConcurrentCreateAndUpdate|TestSQLiteBeginReservesWriter' -count=20
• go test ./internal/app ./internal/handler -count=1
• git diff --check

Fixes #328. Alternative to #329 with the retry latency tightened and broader regression coverage.