perf(nexus): adopt write_batch in NexusContributionStore.put() once nexi-lab/nexus#3700 lands

[windoliver]

Context

NexusContributionStore.put() currently issues N sequential VFS writes for a single contribution:

1. Manifest: /zones/{zoneId}/contributions/{cid}.json
2. One write per relation index entry
3. One write per tag index marker
4. FTS index: /zones/{zoneId}/indexes/fts/{cid}.json

These are independent HTTP calls with no atomicity guarantee. A partial failure (e.g. manifest written, FTS not written) leaves the contribution in an inconsistent index state — discoverable by CID but invisible to list() / search().

Blocked on

nexi-lab/nexus#3700 — expose write_batch on the HTTP/SDK client interface.

write_batch provides true atomic multi-file writes (all-or-nothing, single DB transaction, 13× faster than N sequential writes). Once it is available on NexusClient, this follow-up becomes straightforward.

Proposed change

Once NexusClient.writeBatch() is available:

1. NexusContributionStore.put() (src/nexus/nexus-contribution-store.ts) — collapse the manifest + relation + tag + FTS writes into a single writeBatch call. Eliminates the partial-index-write window and the N×RTT cost.

2. Add writeBatch to NexusClient interface (src/nexus/client.ts) — the interface currently only has single-file write().

What this does NOT fix

Cross-store atomicity (e.g. ClaimStore + BountyStore in claimBountyOperation) requires compensating actions regardless of write_batch, because those stores are logically separate systems. The compensation patterns introduced in #227 stay.

Files

• src/nexus/nexus-contribution-store.ts — put() method, lines 86–153
• src/nexus/client.ts — NexusClient interface, add writeBatch