fix(files_external): S3 folder mtime updated on every read-only access

[Antreesy]

• Resolves: #

Summary

The mtime (and storage_mtime) of an S3 external storage root folder was updated
on every occ files:scan / occ files_external:scan run and on every folder browse
— even when nothing on S3 had changed.

AI findings

Compiled into HTML file here: s3-mtime-propagation.html

How to reproduce

• Connect an S3 external storage and populate it (tested with rustfs S3)
• Create a public share, verify folder mtimes are not updated
• Reload the page, see 'Modified' date updated
• From a public link, access share, read the folder content, download the file
• Alternative: run occ files:scan or occ files_external:scan for the folder
• See 'Modified' date updated on root

---

Root causes (3, fixed independently)

1. Wrong filecache key for the storage root (AmazonS3#getDirectoryMetaData)

normalizePath('') returns '.' for S3 object keys, but the filecache stores the
storage root under the key ''. getDirectoryMetaData() was calling
getCache()->get('.') which looks up by md5('.'), never matching the root entry
stored at md5('').

The cache miss caused getDirectoryMetaData to return synthetic data with time()
as mtime/storage_mtime and uniqid() as etag on every call. The scanner then
saw a storage_mtime mismatch and wrote the fabricated timestamps back to the cache
on every scan run, regardless of whether any S3 content had changed.

Fix: introduce getCachePath() to translate the normalized root path '.' back to
'' before any filecache lookup.

2. Common::getMetaData clobbers storage_mtime (AmazonS3#getMetaData)

Common::getMetaData() always sets storage_mtime = mtime before returning. For S3
virtual directories mtime can be bumped by child propagation while storage_mtime
should remain the actual last S3 change. When the scanner later calls getMetaData()
it compares data['storage_mtime'] against cacheData['storage_mtime']; if they
differ it writes the value back, triggering View::getCacheEntry to fire
propagateChange on every read even when nothing on S3 changed.

Fix: override getMetaData() to restore storage_mtime from the live cache entry
after the parent call.

3. propagateChange() fired unconditionally after watcher update (View#getCacheEntry)

S3's hasUpdated() always returns true for directories (S3 has no cheap global
change-detection mechanism). getCacheEntry() called watcher->update() and then
unconditionally called propagateChange() whenever the watcher reported a change,
meaning every folder browse bumped the parent mtime chain.

Fix: snapshot the cache entry before watcher->update() and compare it with the
entry after. propagateChange() is only invoked when at least one metadata field
(mtime, storage_mtime, size, or etag) actually changed.

---

Before	After

TODO

• ...

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)
• Labels added where applicable (ex: bug/enhancement, 3. to review, feature component)
• Milestone added for target branch/version (ex: 32.x for stable32)

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[Antreesy]

@icewind1991 Can you take another look?

[Antreesy]

Attempted to trim down the changes to minimum
Tested with connected rustfs as S3, with occ commands files:scan, and files_external:scan, neither updates the root folder cache entry with mtime