When a data layer store is stuck syncing (e.g., a delta file missing
from all mirrors), the sync-registries task would detect the root
history mismatch every 5 seconds, log a warn, and return -- repeating
identically forever. This caused massive log noise, unnecessary CPU
from repeated root history + sync status queries, and no useful signal
after the first log entry.

Add per-org mismatch tracking with exponential backoff (30s initial,
2x multiplier, 10min cap) and log throttling (warn on first hit, debug
on retries, info summary every 5 minutes). When the mismatch resolves,
the tracker clears and normal 5s polling resumes immediately.

Update Managed Files

Move duplicated per-org exponential backoff logic from both
sync-registries.js and sync-registries-v2.js into a shared
SyncMismatchBackoff class. Algorithm and log output are identical;
future tuning only needs to change one place.

Add a 1-hour staleness TTL to the org operation lock so that a hung
background operation (promise that never resolves/rejects) cannot
permanently block all future organization operations. When a lock
exceeds MAX_LOCK_AGE_MS, tryAcquireOrgLock force-releases it with a
console warning and allows the new acquisition.

Also add the missing releaseOrgLock() call in the V2 create endpoint's
outer catch block, which could permanently hold the lock if a database
query threw between lock acquisition and the async creation branches.

The outer catch blocks in all 6 guarded handlers unconditionally called
releaseOrgLock(), but the lock is acquired partway through the try
block (after assertions like assertWalletIsSynced). If a pre-lock
assertion throws while another operation holds the lock, the catch
would release that other operation's lock, defeating the concurrency
guard.

Add a lockAcquired flag to each handler, set after successful
tryAcquireOrgLock(), and gate the outer catch release on it.

Replace all bare releaseOrgLock() calls in handler try blocks with a
local releaseLock() closure that atomically checks and clears the
lockAcquired flag before releasing. This eliminates two classes of bugs:

1. Early-release paths (e.g. V1 org detected) left lockAcquired=true.
   Any subsequent await could yield, letting another request acquire
   the lock, and if an error then reached the outer catch it would
   release that other operation's lock.

2. Reclaim handlers had an inner try/finally that released the lock,
   then the outer catch also released — a double-release that could
   free another operation's lock if one was acquired in between.

The only remaining bare releaseOrgLock() calls are inside async
.finally() callbacks on background operations, where lockAcquired is
explicitly set to false at handoff time.

releaseOrgLock() had no concept of who held the lock. When a background
.finally() ran after its operation's lock was force-released due to TTL
expiry, it silently released a different operation's lock, defeating the
concurrency guard.

tryAcquireOrgLock() now returns an opaque ownership token (or null on
failure). releaseOrgLock(token) only releases if the token matches the
current holder, making stale releases a safe no-op. All controllers and
recovery tasks pass captured tokens through their async .finally() and
try/finally blocks.

…k release

updateOrgLockStatus() unconditionally wrote to currentStatus without
verifying the caller owns the lock. After a stale lock force-release
(1-hour TTL), background code from the old operation could overwrite
the new holder's status on the creation-status endpoint.

Change updateOrgLockStatus(status) to updateOrgLockStatus(token, status)
so only the current lock holder can update progress. Thread the lock
token through createHomeOrganization, _resumeOrganizationCreation,
_executeOrganizationCreation, and upgradeFromV1 in both V1 and V2
models, controllers, and recovery tasks.

Also move releaseLock() in the V2 create handler's V1-org check block
from before the async singleton data fetch to just before each return,
closing a window where a concurrent request could acquire the lock
while async I/O was still in flight.

Remove getOrgLockOperation and isOrgLocked exports (only consumed by
tests, not production code). Refactor tests to use getOrgLockStatus()
and add coverage for stale-token rejection.

When a lock-held operation (e.g. upgrade) was running but no Meta-based
creation existed, the creation-status response had inProgress: true
alongside message: "No organization creation in progress" because the
lock-status spread overrode inProgress but not message.

Include a coherent message derived from the lock operation name and
current step. Update the API docs example and add a test assertion
for the message field.

…ency-guard

feat: add in-memory concurrency guard for organization operations

V1 _createStoresInParallel called createDataLayerStore without checking
wallet sync status, causing permanent failure when the wallet
temporarily desyncs. The V2 equivalent already has this protection.

Add waitForSpendableCoins() before V1 store creation and resume paths,
and per-store retry with exponential backoff for transient wallet errors
(matching the V2 implementation).

Extract TRANSIENT_WALLET_ERRORS and isTransientWalletError into
wallet.js so both V1 and V2 models share a single definition. Replace
hardcoded [v2]: log prefix in wallet.js with [wallet]: since the
function is now called from both V1 and V2 paths. Use actual needed
coin count from getStoresToCreate(state) in resume paths instead of
hardcoded 4.

The v1 importOrganization had a chicken-and-egg bug where it checked
datalayer sync status before subscribing to the store. For stores that
were never subscribed, get_sync_status returns an error (store unknown
to datalayer), which was interpreted as "not synced" causing an early
return. The subscription call was never reached, so the store was never
subscribed, and every retry hit the same wall.

Port the subscribe-first pattern already used in v2 importOrganization:
subscribe to the store first (no-op if already subscribed), then check
sync status. This ensures new stores begin syncing on the first pass
and subsequent retries find them progressively more synced.

…et-retry

fix: add wallet readiness check and retry logic to V1 store creation

…e-first

fix: subscribe to org store before sync check in v1 importOrganization

The mirror-check task only mirrored governance stores for governance
body owners (nodes with governanceBodyId/mainGoveranceBodyId in meta).
Subscriber nodes subscribe to governance stores via GOVERNANCE_BODY_ID
in config but the mirror task had no code path to mirror them.

Read GOVERNANCE_BODY_ID from config when meta entries are absent,
mirror the main governance store, then resolve and mirror its version
store via the data model version key.

…ware

The global middleware asserted wallet sync status on every non-health
request, including read-only GETs. When the wallet transiently desyncs
while processing new datalayer block confirmations, all GET endpoints
return 400 even though they only read from the local database.

Skip assertWalletIsAvailable() for GET requests, matching the existing
pattern where the home org sync check already allows GETs through.
Write operations still require the wallet to be synced.

Replace manual subscribe/import flow in test-v2-remote-sync with
automatic governance-based discovery. Add faucet funding, mirror
creation validation, and mirror cleanup. Create new parallel
test-v1-remote-sync job with identical structure using V1 config,
governance, and data validation against the V1 participant instance.

subscribeToStoreOnDataLayer unconditionally created a mirror on every
subscribe, ignoring AUTO_MIRROR_EXTERNAL_STORES. Gate the addMirror
call on the config setting (defaulting to true) so users who set it
to false do not get mirrors for external stores.

Also update the README to clarify that both AUTO_MIRROR_EXTERNAL_STORES
and DATALAYER_FILE_SERVER_URL must be configured for external store
mirroring to function.