docs: say what the FatFs sector floor actually guards

The comment claimed a block below the sector size cannot back a coherent
on-disk record layout. Nothing in Core depends on sector alignment or on a
block write being atomic, and the adapter writes through byte-granular
f_write, so what a sub-sector block costs is a read-modify-write per block.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: DavidCozens

Platform/FatFs/Source/SolidSyslogFatFsFile.c

@@ -15,11 +15,11 @@
 #include "SolidSyslogTunables.h"
 #include "ff.h"
 
-/* The shared file-block-size default must clear one FatFs sector - a block
- * smaller than the underlying sector cannot back a coherent on-disk record
- * layout. FF_MAX_SS comes from the integrator's ffconf.h; guard with defined()
- * so the check is skipped (rather than evaluating an undefined identifier) on
- * any configuration that does not expose it. */
+/* The shared file-block-size default is held at or above one FatFs sector: a
+ * block below the sector size makes every block write a sector
+ * read-modify-write. FF_MAX_SS comes from the integrator's ffconf.h; guard with
+ * defined() so the check is skipped (rather than evaluating an undefined
+ * identifier) on any configuration that does not expose it. */
 #if defined(FF_MAX_SS) && (SOLIDSYSLOG_FILE_DEFAULT_BLOCK_SIZE < FF_MAX_SS)
 #error "SOLIDSYSLOG_FILE_DEFAULT_BLOCK_SIZE must be >= FF_MAX_SS (one FatFs sector)"
 #endif