ccache served stale object files after a codegen field rename

While renaming book.ledger_ccy to book.functional_currency (codegen-regenerated book_mapper.cpp, book_entity.cpp, book_repository.cpp, book_registrar.cpp, book_service.cpp, book_history_field_mapper.cpp), several of the corresponding .cpp.o object files in ores.refdata.core.lib kept a compiled-in INSERT=/=SELECT column list containing the old ledger_ccy name — confirmed via strings <file>.cpp.o | grep ledger_ccy against each object file individually, even though the corresponding .cpp source (confirmed via plain grep) had zero occurrences and a correct, later mtime. ccache -s showed a 96% direct-mode hit rate. Deleting just the offending .o files and relinking wasn't sufficient (still-stale sibling files elsewhere in the same directory); the fix that worked was removing the whole CMakeFiles.*.dir build directories for the affected libraries, reconfiguring (cmake --preset ..., since deleting the dir also deletes the generated Makefiles), and rebuilding with CCACHE_DISABLE=1.

Investigate whether this is a ccache direct-mode hashing gap specific to how codegen writes regenerated files (e.g. a mtime/inode reuse pattern that direct mode's file-signature cache misreads as unchanged), and whether a CCACHE_SLOPPINESS tweak or a codegen-triggered targeted =ccache -Z=/cache-clear for touched files would prevent this recurring on the next field rename.

This class of failure is dangerous specifically because it's silent at compile time — the build reports success, tests that don't hit the live DB pass, and only a live query against the (correctly) renamed schema surfaces the mismatch as a runtime SQL error. It cost several rebuild-and-reprovision cycles to root-cause during the functional_currency rename task, and will recur on any future codegen-driven rename that touches multiple sibling .cpp files in one component.

• Surfaced during Task: Rename ledger_ccy to functional_currency.