### System details

Code-level reproduction on macOS with Bash; reviewed commit b679363bed05415771a1b1dc92c6899a908236f7. No installed Omarchy desktop or omarchy-debug output; scope and stat adapter described below.

### What's wrong?

## Summary

`omarchy-menu-images` reuses cached thumbnail rows after an existing image is overwritten in place. The fast signature only includes each directory's mtime, which does not change when the contents of an existing file change. A cache hit then bypasses the per-file size/mtime checks and keeps the old thumbnail path.

This is an AI-assisted code-review report. The cache-decision block was reproduced in isolation on macOS, not in a running Omarchy desktop. No claim of end-to-end GUI testing is intended.

## Affected code

Reviewed commit: `b679363bed05415771a1b1dc92c6899a908236f7`.

- [Directory-only signature and early cache hit](https://github.com/omacom/omarchy/blob/b679363bed05415771a1b1dc92c6899a908236f7/bin/omarchy-menu-images#L121-L143)
- [Per-image signature used when thumbnail_for actually runs](https://github.com/omacom/omarchy/blob/b679363bed05415771a1b1dc92c6899a908236f7/bin/omarchy-menu-images#L201-L214)

## Isolated reproduction

Run the following with Bash from a checkout of the reviewed commit. All fixtures are created in a new temporary directory. The cached row and media bytes are synthetic: this tests invalidation, not decoding or the UI. The macOS adapter only changes how the directory mtime is read; Linux uses GNU stat directly.

```bash
review_source="$PWD/bin/omarchy-menu-images"
review_root=$(mktemp -d)
review_images="$review_root/images"
mkdir "$review_images"
printf 'old image bytes' >"$review_images/example.png"

if [[ $(uname -s) == Darwin ]]; then
  stat() { command stat -f '%m' "$3"; }
fi

image_dirs=("$review_images")
rows_cache_file="$review_root/cached.rows"
rows_fast_signature_file="$review_root/cached.fast-signature"
review_mtime=$(stat -Lc '%Y' "$review_images")
printf '%s\t%s' "$review_images/example.png" old-thumbnail.jpg >"$rows_cache_file"
printf 'v3\n%s:%s\n' "$review_images" "$review_mtime" >"$rows_fast_signature_file"

printf 'new image bytes with a different size' >"$review_images/example.png"
[[ $(stat -Lc '%Y' "$review_images") == "$review_mtime" ]] || exit 1
rows_fast_signature=$'v3\n'
rows_signature=$'v4\n'
rows_cache_hit=false
image_files=()
rows=''

# Exact cache-decision block at the commit linked above.
eval "$(sed -n '121,143p' "$review_source")"
printf 'rows_cache_hit=%s\nrows=%s\n' "$rows_cache_hit" "$rows"
printf 'Test fixtures retained at %s\n' "$review_root"
```

Observed output (temporary paths shortened):

```text
rows_cache_hit=true
rows=/tmp/.../images/example.png<TAB>old-thumbnail.jpg
```

The changed file size is never examined because the directory-only signature still matches. The subsequent row-building code is gated by `rows_cache_hit != true`, so it cannot regenerate the thumbnail on this path.

## Expected behavior / user impact

After an existing wallpaper or preview image is saved in place, reopening the selector should invalidate the corresponding thumbnail. Currently the cache decision continues to select the previous thumbnail until another event invalidates the directory cache. Editors that save by atomic replacement may change the directory mtime and therefore not trigger this case.

## Related work

The "Note on staleness" in #8922 explicitly mentions this existing limitation. That PR addresses unreadable images and index performance, rather than invalidation of successfully cached images changed in place. Searches for existing image-selector/thumbnail issues did not find a dedicated report for this behavior; please link one if this is already tracked.

## Possible fix

Check cached media files' metadata before trusting the row cache, or use content-change notifications to invalidate it. A regression test should populate a successful row cache, overwrite an existing image with a different size without changing the directory mtime, and verify that the old thumbnail is no longer reused.