feat(map): add first-writer-wins claim API on SharedDirectory

[kian-thompson]

Description

Adds an opt-in first-writer-wins claim API on ISharedDirectory:

• trySetClaim(key, value): Promise<ClaimResult> — attempts to claim a root-level key. Resolves to "Success" if this client won, or "AlreadyClaimed" if another client's claim was sequenced first. Repeated calls from the original winner also resolve "Success".
• isClaimed(key): boolean — returns true if the root-level key is currently claimed.

Once a key is claimed, the value is immutable: set and delete for that key throw UsageError, get returns the claimed value, and clear() does not remove claims. Claims are persisted in the summary and survive load (on rehydrate, no client is treated as the original winner).

The API is gated behind a runtime opt-in (enableDdsClaims: true on the data store runtime options). Calling trySetClaim or isClaimed without the flag throws UsageError. Claims are only available on the root ISharedDirectory; subdirectories intentionally do not expose them.

Implementation notes:

• New "claim" op type with its own message handler, rollback path, resubmit path, and stashed-op replay.
• New optional claims field in the IDirectoryNewStorageFormat summary blob (back-compat: absent on older snapshots).
• Pending claim deferreds are resolved on dispose to avoid hangs.

Reviewer Guidance

The review process is outlined on this wiki page.

• Open question: while offline, the trySetClaim promise stays pending until reconnect (or dispose). Should we add an AbortSignal parameter or a disconnected-aware result, or just document the behavior? Marking as draft pending this discussion.
• The applyStashedOp path re-submits a fresh claim op rather than reusing the stashed op directly — feedback welcome on whether that's the right approach.
• New mocha tests live in packages/dds/map/src/test/mocha/directory.claims.spec.ts.

[github-actions]

Hi! Thank you for opening this PR. Want me to review it?

Based on the diff (593 lines, 9 files), I've queued these reviewers:

• Correctness — logic errors, race conditions, lifecycle issues
• Security — vulnerabilities, secret exposure, injection
• API Compatibility — breaking changes, release tags, type design
• Performance — algorithmic regressions, memory leaks
• Testing — coverage gaps, hollow tests

How this works

• Adjust the reviewer set by ticking/unticking boxes above. Reviewer toggles alone don't trigger anything.

• Tick Start review below to dispatch the review fleet.

• After review finishes, tick Start review again to request another run — it auto-resets after each dispatch.

• This comment updates as new commits land; your reviewer selections are preserved.

• Start review

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> fluid-framework-docs-site@0.0.0 ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> fluid-framework-docs-site@0.0.0 serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> fluid-framework-docs-site@0.0.0 check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

Stats:
  288641 links
    1922 destination URLs
    2172 URLs ignored
       0 warnings
       0 errors