fix: improve shard publish error logging
Summary
- log the temporary and final paths, concrete OS error type, and filesystem state when publishing a shard fails
- preserve the first build error so a later stale-shard cleanup failure does not hide the original rename failure
- add a regression test covering simultaneous publish and cleanup failures
Motivation
We observed an index build report only remove ...: no such file or directory after logging that a shard had finished. The actual preceding temp-to-final rename error was not logged and was subsequently overwritten, obscuring whether the failure came from SMB rename semantics or concurrent cleanup.
Testing
go test ./...
[!NOTE]
Low Risk
Localized observability and error-handling change in index Finish; behavior on success is unchanged, with a regression test for the failure path.
Overview
Builder.Finish now keeps the first failure during shard publish and cleanup instead of letting a later step replace it—so a misleading cleanup error (e.g. remove: no such file) no longer hides a failed temp→final rename.
On rename failure it logs temp/final paths, the concrete OS error type, and fileState (mode, size, modtime) for both paths, and wraps the error as publishing shard: rename .... Other late-stage errors (old path discovery, tombstones, removing stale shards) go through the same recordBuildError helper with clearer messages where applicable.
Adds TestBuilderFinishPreservesShardPublishError when the final shard path is a non-empty directory so publish and cleanup both fail but the returned error still mentions publishing.
Reviewed by Cursor Bugbot for commit e2c34e01dcfa12a7bce4c774d5d4e4a4c4dc7692. Bugbot is set up for automated code reviews on this repo. Configure here.