chore(locks): audit and retag every TODO:[Locks] marker (#2040)

[Taewa]

Closes #2040.

Audit of every TODO:[Locks] marker. No behaviour changes — comments, one shared test fixture, and the docs.

grep -rn "TODO:\[Locks\] #1998" src/ now returns zero.

Removed — already resolved

Where	Why
models/post/details/postDetails.ts	The comment explained that lock is assigned in the constructor. Every sibling field is too, so it said nothing.
services/nexus/nexus.types.ts	Claimed the field was mock-only and blocked on pubky-app-specs#136. That issue is closed and the real publish flow writes the field.
organisms/DialogLocksAuth	Asked for the /connect iframe sandbox set to be verified against the live flow. Verified on dev.
organisms/LockedPostContent	Asked for a decision on the unparseable-teaser case. Rendering nothing is the decision; kept a one-line note.

Retagged

Marker	From	To
dev-static + password verifier (6 places)	#2040	#2369
Locked-post card indicator hardcoded to password	#1998	#2369
Reading back your own locked content when the pubkys differ (2 places)	#1998	#2283
creatorPubky missing on the SDK session	untagged	#2283
Lock files not cached in IndexedDB	#1998	#2296
SDK shipped as the web build, so init() is needed	untagged	#2372
Recovery after a paid unlock partially fails	#2040	#2374 (new)
LockFile type hand-mirrored from the SDK	#1998	pubky/locks#22 (new)
Creator responses handed to JS unparsed (6 → 1 marker)	#2040	pubky/locks#22 (new)
Content type read from lock.json instead of the response header	#1998	pubky/locks#10

Added

• useCreateLockContent — the publish path builds a lock URL and posts it without running it through isValidLockUrl, which the read path already does. Marked, not fixed.

Also

• The lock.json test fixture was copied verbatim into three test files. Moved to src/test-utils/locks.ts as mockLockFile().
• docs/locks.md — dropped the marker tables. They duplicated what grep and the issues already say, and had already drifted.

Filed upstream

• SDK: parse creator API responses into typed structs, like viewer responses already are locks#22 — creator responses skip the typed parse that viewer responses get.

Not in scope

#2312 is a real bug that is now unblocked (#2027 closed, PubkyAppPost.new_with_lock exists), but #1998 moved it out of the epic. Left as is.

[greptile-apps]

Greptile Summary

This PR audits and retags Locks TODO markers without changing production behavior.

• Retags or removes stale Locks markers and updates the Locks documentation.
• Consolidates duplicated lock test data into a shared fixture.
• Documents deferred validation of lock URLs on the publish path.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed

Filename	Overview
src/hooks/useCreateLockContent/useCreateLockContent.ts	Adds documentation for deferred publish-path lock URL validation; executable behavior is unchanged.
src/test-utils/locks.ts	Introduces a typed shared lock-file fixture matching the duplicated fixtures it replaces.
docs/locks.md	Updates Locks contracts, marker tracking, and shared-fixture documentation.
src/core/application/locks/locks.ts	Retags and consolidates deferred-work comments without changing application logic.

_{Reviews (2): Last reviewed commit: "docs(locks): update the release-gate mar..." | Re-trigger Greptile}

[Taewa]

@greptile-apps
Review again please.

[Orlandohub]

It looked good for me overall therefore will approve.

Leaving some comments from AI

[P2] Preserve tracking for the unvalidated registerGuardedResource response.
locks.ts:262 still casts and trusts an unparsed creator response, but this PR removes its TODO and only tracks createContentLock. pubky/locks#22 explicitly covers both endpoints. Retag this call to that issue or validate its response now; otherwise malformed creator/resource values can produce unreachable attachment URIs while the remaining TODO no longer points reviewers here.

[P2] The audit introduces an unowned marker despite requiring issue ownership.
useCreateLockContent.ts:90 adds a bare TODO even though docs/locks.md:117 says every shortcut carries its owning ticket, and closing issue #2040 requires deferred work to be retracked rather than left bare. The head has 25 Locks markers, three without identifiers. I would reopen the existing resolved Greptile thread or change the documented convention explicitly.

[Taewa]

@Orlandohub
Thanks both P2s are intentional.

1. There were many duplicated TODOs for one single issue. I left one TODO for that and once Lock-SDK support it, I will use AI to update pubkyApp code.
2. These TODOs without number is something that "not urgent and I leave in the code so we can improve in the future"