Verify DFHack 53.15-r3 proto sync (no-op)

[Copilot]

What & why

DFHack 53.15-r3 may introduce RPC protocol changes via updated .proto definitions. This PR verifies the vendored proto set is already in sync with that release and confirms no codegen or wire-format changes are required.

• Scope checked
  • Compared all vendored proto/*.proto against DFHack 53.15-r3 upstream sources:
    • library/proto/*.proto
    • plugins/remotefortressreader/proto/*.proto
• Outcome
  • No file diffs found across the full vendored proto set.
  • build/proto.json remains unchanged after regeneration.
• Protocol impact
  • No RPC schema delta; no wire-format behavior change.

diff -u /home/runner/work/dfhack-remote-node/dfhack-remote-node/proto/CoreProtocol.proto \
       <upstream-53.15-r3>/library/proto/CoreProtocol.proto
# no output (identical)

How it was verified

• npm run typecheck clean
• npm run lint clean
• npm run build succeeds
• npm test passes (offline protocol test)
• If the protocol changed: re-ran npm run gen-proto and committed build/proto.json

Notes

No repository file changes were necessary for 53.15-r3.

• Fixes Update for DFHack 53.15-r3 #10

[alexanderolvera]

Closing without merging — the audit result is right, but the branch is not a no-op.

The vendored protos really are in sync. I re-verified independently by comparing git blob SHAs against DFHack 53.16-r1.1, and all 8 files match upstream byte-for-byte:

File	Upstream	Blob SHA
Basic.proto	library/proto/	f4ca8263
BasicApi.proto	library/proto/	3c0fb1a1
CoreProtocol.proto	library/proto/	b2f7d2be
AdventureControl.proto	plugins/remotefortressreader/proto/	6fc6020a
DwarfControl.proto	plugins/remotefortressreader/proto/	2babc996
ItemdefInstrument.proto	plugins/remotefortressreader/proto/	45c35f69
RemoteFortressReader.proto	plugins/remotefortressreader/proto/	b7dc7bdc
ui_sidebar_mode.proto	plugins/remotefortressreader/proto/	df81d6bd

Since the current tree matches the newest release, it is by definition current for every release before it.

The reason this can't be merged: despite being described as a no-op, the branch carries a package-lock.json diff that strips "peer": true from ~20 entries. That's churn from resolving the lockfile under an older npm, and merging it would quietly rewrite dependency metadata as a side effect of a verification task. A genuine no-op should have an empty diff.

Tracking issue closed alongside this.

[alexanderolvera]

Correction to the note above: the lockfile paragraph applies to #13 and #15, not to this one. This branch has an genuinely empty diff — it is a true no-op, closed simply because there is nothing to merge. The verification result stands either way.