Update modified time when closing written files

[Old-Ding]

Closes #81 ## Summary - Add ffconfigUPDATE_FILE_MODIFIED_TIME_ON_CLOSE, defaulting to 0 to preserve existing close-time behavior. - Track actual file changes with FF_VALID_FLAG_MODIFIED after successful writes or EOF truncation, including partial writes and completed cluster writes followed by a later error. - Reuse the existing FF_Close() directory-entry update to refresh xModifiedTime when the opt-in config is enabled. - Keep the ff_file metadata tests on narrow mock subsets instead of generating the full ff_ioman.h mock surface. ## Testing - git diff --check - cmake -S . -B _build/project -G Ninja -DFREERTOS_PLUS_FAT_TEST_CONFIGURATION=DEFAULT_CONF -DFREERTOS_PLUS_FAT_PORT=POSIX - cmake --build _build/project --target freertos_plus_fat_build_test --parallel - The four ff_file CMock tests pass in a local MinGW harness, including later block-write failure and successful cluster write followed by FAT traversal failure. - Uncrustify 0.69.0 --check passes for ff_file.c and test/unit-test/ff_file_utest.c. - The native MinGW CMake unit-test target cannot link CMock's shared mock library because its strict-order globals are defined by the test runner. The local harness links the same generated mocks and runner into one executable; the official unit-test job runs on Ubuntu. ## CI notes

• 7048dca adds FF_DecreaseFreeClusters to the narrow ff_ioman mock subset, resolving the ff_file_utest link error from the previous run.
• The CI workflow for current head 7048dcaab964a73acafe367a07a4c2cc5780c68f is action_required with no jobs. It is awaiting maintainer workflow approval before the unit-test matrix can run.

[Old-Ding]

Follow-up verification:

• The implementation follows the direction discussed in [BUG] FF_Close() does not update xModifiedTime with current system time when file is modified (ffconfigTIME_SUPPORT=1) #81: the new behavior is opt-in through ffconfigUPDATE_FILE_MODIFIED_TIME_ON_CLOSE, defaulting to 0 to preserve existing close-time behavior.
• The timestamp update reuses the existing directory-entry write in FF_Close(), so it does not add a second FF_GetEntry() / FF_PutEntry() cycle for modified files.
• Unit tests were added for the unchanged-size modified-file case and the unmodified-file case, and git diff --check upstream/main...HEAD passes.

I still do not have CMake/Ruby/a C toolchain available on this Windows host to run the new unit test locally.

[rawalexe]

Verified the xUpdateDirectoryEntry gating: it's correctly OR'd — set independently in the size-changed block and the modified-flag block, both writing into the same xOriginalEntry before a single consolidated FF_PutEntry. No clobbering between the two triggers. Nice disk-I/O consolidation.

One open question: is FF_VALID_FLAG_MODIFIED guaranteed to be cleared/reset before a file handle is reused from the pool, in case FF_PutEntry fails here? Not blocking since the handle appears to be freed/reset elsewhere in FF_Close, but worth a quick confirmation or a test case for the failed-write path.

Feature is opt-in (ffconfigUPDATE_FILE_MODIFIED_TIME_ON_CLOSE default 0) so zero-cost by default. LGTM.