#1731 Double shard assembly per command lifecycle (pull + push both read all shards)

Summary

Both pullChanged (line 1672) and pushChanged (line 2009) independently call assembleIndexFromShards(), each reading _meta.json + N partition shard files from S3. When the fast path is broken (see companion issues), this happens on every command — the shards are fetched twice.

pullChanged populates this.index with the assembled entries, but pushChanged ignores it and re-fetches everything from S3 to get a fresh view. For read-only commands where nothing was dirtied between pull and push, this is wasted work.

Impact

With the fast path broken, every command does 2x the S3 reads for shard assembly. For a repo with ~20-30 shards, that's 40-60+ S3 GetObject calls instead of 20-30.

Suggested fix

Two options:

1. Cache-aware assembly: If this.index is already populated from a recent pullChanged in the same process lifecycle and localDirty is false (nothing was written between pull and push), skip the push-side assembly and reuse the pull's index.

2. Two-phase sync refactor: Core already supports preparePush/commitPush (two-phase sync). If core uses two-phase, the same assembly can serve both pull verification and push preparation.

References

• s3_cache_sync.ts:1672 (pullChanged shard assembly)
• s3_cache_sync.ts:2009 (pushChanged shard assembly)
• assembleIndexFromShards() reads _meta.json + all partition files

Upstream repository: https://github.com/systeminit/swamp-extensions

Environment

• Extension: @swamp/s3-datastore@2026.08.12.1
• swamp: 20260819.011806.0-sha.a9c7ee9a
• OS: darwin (x86_64)
• Deno: 2.8.3
• Shell: /bin/zsh