backlog: amend #1112 -- the concurrent-uploads half is answered, the cross-shard half is what remains

[wshallwshall]

Docs-only. #1112 stays OPEN -- this is an amendment, not a closure. No new number was allocated, deliberately.

Why no new number

The owner asked for the store-side ASVS 2.3.4 fix to be filed. The ASVS lane ran the duplicate check before drafting and it fired: #1112's own title already reads "a quota that holds across concurrent uploads and across engine shards at once." The store-side fix is its second half.

Filing it fresh would have burned a number on a duplicate -- the failure section 7 records twice, and which I made myself today on the glyph item. Running the check first is the whole reason it did not happen again.

Verified against origin/main, not taken on report

uploads.py:309   self._quota_lock = asyncio.Lock()                      (PR #325)
uploads.py:488   async with self._quota_lock:   ... :496 _scan_metas_sync()
"the check-then-write is not atomic"   0 occurrences  -- and there is no line 394
settings.py:439  "engine shards sharing one dir see each other's files and the budget
                  does NOT multiply (measured 2026-08-10 ... live positive control)"

Two strikes, both false in the ALARMING direction

1. The banner's "no lock constructed in the module" and its :394 citation. The lock exists and is held across both the scan and the write -- releasing between them was the race.
2. The severity paragraph's "N engine shards would each apply the budget separately, multiplying it." The real remainder is an at-most N-1 file overshoot, one per competing shard caught between its scan and its file landing, each bounded by max_upload_bytes.

Both struck rather than deleted. An overstated severity is not the conservative error -- it misdirects whoever costs the fix, and this one overstated by a multiplier.

What actually keeps it open -- one sentence

asyncio.Lock is per-event-loop, therefore per-process, and the module says so itself at :487: "One critical section per process." Engine sharding is the built, shipped, default scaling axis, and nothing partitions uploads_dir per shard -- so N shards over one directory hold N independent locks.

The fix has a known home, so "cannot honestly reach pass" is not the finding here: ADR 0063 already puts every shard on one unified store, so the cross-shard coordination point exists. Move the quota accounting into the store, or take an advisory lock on the directory.

Acceptance is stated as EXECUTION, never as reading: the quota holds across N shards sharing one uploads_dir, with concurrent writers on at least 2 shards, and the single-process path keeps its current behaviour.

Owner ruling, recorded in the item: ASVS 2.3.4 holds at partial -- V2.3.4 names business-logic locking as the means, and a per-process lock does not span a resource shared across processes.

One blind check I caught in myself

My first grep for the struck string ran against messagefoundry/api/uploads.py -- which does not exist; the file is messagefoundry/uploads.py. It printed 0 and I labelled it "the string is gone." Right answer, no evidence. Re-ran against the real path with a negative control (49 def/class lines) before believing it.