[Bug] set: a command that fails (unknown sheet) still rewrites and re-saves the file, with the audit stamp

Summary

A set that fails (here: unknown sheet) exits 1 with a clear error, but the file on disk is still rewritten and re-saved: parts are re-serialised, docProps/custom.xml gains the OfficeCLI.Version / OfficeCLI.LastModified audit stamp, and the SHA-256 changes. Happens both with OFFICECLI_NO_AUTO_RESIDENT=1 and in the default resident mode (visible after close).

Environment

officecli 1.0.149 (Homebrew, dotnet 10.0.400), macOS 26.4.1 arm64.

Reproduction

Any .xlsx works; this uses the file from #389 (a sheet with a chart):

cp min_order.xlsx f1.xlsx
shasum -a 256 f1.xlsx
OFFICECLI_NO_AUTO_RESIDENT=1 officecli set f1.xlsx /NoSuchSheet/A1 --prop value=1
# Error: Sheet not found: "NoSuchSheet". Available sheets: [Sheet1]. ...
echo $?          # 1
shasum -a 256 f1.xlsx   # different

Parts that differ between input and output: xl/worksheets/sheet1.xml, xl/charts/chart1.xml, _rels/.rels, xl/workbook.xml, [Content_Types].xml; docProps/custom.xml is added with the two OfficeCLI.* properties.

Same in resident mode:

cp min_order.xlsx f2.xlsx
officecli set f2.xlsx /NoSuchSheet/A1 --prop value=1   # exit 1
officecli close f2.xlsx
shasum -a 256 f2.xlsx   # different

A plain get on the same file leaves it byte-identical, as expected.

Why it matters

Combined with the element-order bug in #389, a command that did nothing turns a good workbook into one Excel wants to repair. More generally, an audit stamp saying OfficeCLI modified the file is written for a command that was refused.

Expected

A command that fails before mutating anything leaves the file untouched: no re-serialisation, no audit stamp, same hash.