--auto silently skips files that --auto --check flags (stale incremental cache)

## Summary

With the incremental cache enabled (the default), `flowmark --auto ` can exit 0 and leave a file **unchanged** even though it still needs reformatting, while `flowmark --auto --check ` correctly reports `Would reformat` (exit 1) for the same file.

The writer and the checker disagree. In practice this means `make format` (auto-format) cannot fix what `make format-check` / CI (`--auto --check .`) rejects — and the formatter reports success while changing nothing. It is silent: a project's auto-format looks like it ran clean, drift accumulates, and the check keeps failing with no way to resolve it via the documented commands.

## Observed (flowmark-rs 0.3.1)

For a Markdown file that needs a smart-quote fix:

```
$ flowmark --auto FILE # exit 0, FILE unchanged
$ flowmark --auto --check FILE # "Would reformat: FILE", exit 1
```

The formatter is capable — the pending change is real:

```
$ flowmark --semantic --cleanups --smartquotes -o /tmp/out FILE
$ diff FILE /tmp/out # shows the pending smart-quote change
```

Clearing the cache resolves it:

```
$ flowmark --clear-cache # or: rm -rf ~/Library/Caches/flowmark
$ flowmark --auto FILE # now reformats correctly
```

**flowmark-py 0.7.2 is not affected** — it has no incremental cache and reformats the same file correctly, with its `--auto` (writes) and `--auto --check` (exit 1) in agreement.

## Cache details

Per-path entries at `~/Library/Caches/flowmark/incremental/.toml`:

```toml
fingerprint = "…"
hashes = ["…"]
version = 1
```

It looks like `--auto` (the write path) trusts a cached "clean" hash, while `--auto --check` recomputes — so a stale or incorrect `hashes` entry makes the two paths disagree about whether the file needs reformatting.

## Reproducer

I was not able to reduce this to a minimal synthetic case: cache invalidation behaves correctly in isolated tests (fresh files, `--check` then `--auto`, flag-set mismatches, mtime tricks all reformat correctly). The bad state arose after extended real-world use — repeated `--auto .` and `--auto --check .` runs over the same files.

It reproduces reliably on `docs/general/editorial/groundwork-template.md` in `jlevy/k-guide` (the version immediately before commit `e3d4629`): `--auto` left the file unchanged, `--auto --check` flagged it, and clearing the cache fixed it. Happy to capture and attach the exact file + poisoned cache entry.

## Suggestion

`--auto` and `--auto --check` should never disagree about whether a file needs reformatting — both paths should consult (or ignore) the cache identically, and the write path should not trust a cached "clean" result the check path would reject. `--no-cache` is a usable workaround in the meantime.