Run-1 read-back: refuse or warn about volatile FHIR meta.* field_paths #1791

The first-run read-back (compile_agent.harness.RecordReadBack, #1542) compares whole records. With the default FHIR field_paths this is safe, because meta.* isn't mapped. If a verify.yaml maps meta.lastUpdated or meta.versionId into field_paths, run 1 stops as wrong_record on every save, because the server changes those fields on every read. #1779 shows this with a local FHIR server in tests/test_readback_volatile_fields.py.

This fails closed, but every first run on such a contract stops for nothing. Adding the field to records_drop_fields fixes it.

Proposal: when a run-1 verifier is loaded, refuse a contract that maps a server-managed field (meta.lastUpdated, meta.versionId, and the equivalents for other record kinds) unless that field is also listed in records_drop_fields. The message should name the field and the fix. Keep it a refusal, not a silent drop, so a contract that really means to check those fields has to say so.

db_snapshot isn't affected: it isn't a read-back source, and the contract frame has its own ignore_columns.