Re-evaluate the local concurrency model for a shared-service context

[JSONbored]

Problem: The miner's local-store concurrency guarantees were explicitly designed for two local processes sharing one file — that model doesn't automatically translate to many remote users against one shared hosted service.

Area: AMS / Cloud architecture (src/selfhost/installation-concurrency-admission.ts, src/queue/map-with-concurrency.ts — the existing single-instance concurrency primitives to re-evaluate).

Unblocked (2026-07-21): the dependency this issue was waiting on — migrating AMS's local-store layer to a shared datastore — is done (#7175, closed: AMS's local-store layer migrated from node:sqlite to the shared pg-adapter/SqliteDriver seam). This issue is no longer blocked.

Proposal: Verify the now-real shared backend's own concurrency guarantees under actual concurrent load, and document them explicitly rather than assuming the old local-file assumptions still silently hold.

Deliverables:

• A documented concurrency model for the shared pg-adapter/SqliteDriver backend (what's guaranteed, what isn't) under real concurrent access from multiple tenant sessions.
• A load test exercising real concurrent read/write access, verifying no lost updates / no race conditions that the old single-file model implicitly relied on.

Resources

• Migrate AMS's local-store layer (node:sqlite) to the shared pg-adapter/SqliteDriver seam #7175 (closed — the shared-datastore migration this depends on)
• src/selfhost/installation-concurrency-admission.ts, src/queue/map-with-concurrency.ts (existing single-instance concurrency code, for contrast)

Contributor-eligible. Verification/documentation work against an already-migrated, already-real backend — no undecided architecture question left to resolve, no infra credentials needed (test against the existing test-double Postgres/SQLite setup, not live infrastructure).

[linear-code]

JSO-3601