fix(keystore): per-file mtime/size for keyfile updates (+ test fixes)

[lbayas]

Why this should be merged

Without the keystore change, replacing a keystore JSON at the same path may not refresh the in-memory account index, so Accounts() and unlock flows can disagree with disk—a real correctness bug for rotate/swap workflows.

The Influx and geth changes are small test-only fixes that remove flaky or vet-failing behaviour on current Go/tooling (e.g. arm64) and match what CI runs under make test.

How this works

• accounts/keystore/file_cache.go: For paths already known from the last scan, compare stored per-file mod + size to the current Stat; if either changed, treat as an update (in addition to the existing ModTime.After(lastMod) path for new files / clock movement).
• accounts/keystore/account_cache.go: Initialise fileStat map in newAccountCache.
• metrics/influxdb/influxdb_test.go: Before comparing HTTP body to golden files, canonicalise stddev= / variance= float text so tiny platform float formatting differences do not fail the test.
• cmd/geth/logging_test.go: Log diff output with t.Log(...) instead of t.Logf(...) so vet does not flag a non-constant format string.

How this was tested

• go test -count=1 -vet=all ./accounts/keystore/ ./metrics/influxdb/ ./cmd/geth/
• go test ./accounts/keystore/...
• make test

[ARR4N]

Thanks for your contributions, @lbayas, especially #277.

One of the guiding principles of libevm is that we fastidiously minimise changes relative to upstream geth, only adding configurations with backwards-compatible defaults, and cherry-picking from future versions when a critical patch is released. As such, my review might seem very strange and nit-picky! The rationale is that it keeps merge conflicts to the smallest possible footprint.

Is the key-file issue something that is currently causing problems for you / someone else? Or is the intention more to ensure correctness. I'm very happy to accept changes that make libevm more useful for people (i.e. the former), but also need to balance that with not introducing unnecessary changes (i.e. the latter).

[lbayas]

Thanks for your contributions, @lbayas, especially #277.

One of the guiding principles of libevm is that we fastidiously minimise changes relative to upstream geth, only adding configurations with backwards-compatible defaults, and cherry-picking from future versions when a critical patch is released. As such, my review might seem very strange and nit-picky! The rationale is that it keeps merge conflicts to the smallest possible footprint.

Is the key-file issue something that is currently causing problems for you / someone else? Or is the intention more to ensure correctness. I'm very happy to accept changes that make libevm more useful for people (i.e. the former), but also need to balance that with not introducing unnecessary changes (i.e. the latter).

Understood @ARR4N and agree 👍.

For clarity, the geth adjustment in this PR was primarily to address the following test failure when running make test against SHA d71b6cc8513a9e2df3952bec79a6076df98cd60a (main):

lbayas@Lukes-MacBook-Pro-2 libevm % go test -count=1 -tags=ckzg,integrationtests -vet=all -p 1 ./cmd/geth/

# github.com/karalabe/usb
In file included from ../../go/pkg/mod/github.com/karalabe/usb@v0.0.2/libs.go:50:
../../go/pkg/mod/github.com/karalabe/usb@v0.0.2/libusb/libusb/os/darwin_usb.c:53:29: warning: macro 'ATOMIC_VAR_INIT' has been marked as deprecated [-Wdeprecated-pragma]
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/17/include/stdatomic.h:62:41: note: macro marked 'deprecated' here
# github.com/ava-labs/libevm/cmd/geth
# [github.com/ava-labs/libevm/cmd/geth]
cmd/geth/logging_test.go:93:11: non-constant format string in call to (*testing.common).Logf
cmd/geth/logging_test.go:143:11: non-constant format string in call to (*testing.common).Logf
cmd/geth/logging_test.go:213:10: non-constant format string in call to (*testing.common).Logf
cmd/geth/logging_test.go:234:10: non-constant format string in call to (*testing.common).Logf
FAIL    github.com/ava-labs/libevm/cmd/geth [build failed]
FAIL

In retrospect, opening an issue to discuss/prioritize cmd/geth test failures would have been a better approach than submitting a PR.

The same perspective likely applies to metrics/influxdb test failures, which is likely out of scope given your initial comments.

With that, I’ll go ahead and respectfully close this PR, thanks for the guidance!

[ARR4N]

No need to close it if the keystore stuff is still an issue for you. We'll need to look at how we do it, but I'm open to merging that if necessary.