Add recovery API to repair filesystem catalog's latest snapshot pointer

[manuzhang]

Depends on the filesystem catalog issue.

A filesystem catalog uses version-hint.text as the latest-version pointer. Crashes between writing vN.metadata.json and updating version-hint.text can leave the pointer trailing the actual latest committed metadata. Recovery should:

1. List metadata/v*.metadata.json
2. Parse each, identify the highest version with a consistent snapshot lineage
3. Optionally rewrite version-hint.text to point at it (or surface the discrepancy and let the caller decide)

Spark/Java avoid this entirely because the fix is implicit on next read (HadoopTableOperations rescans), but a C++ embedded user committing in a long-lived process needs an explicit recovery entry point.

API sketch

class FilesystemCatalog : public Catalog {
  Result<int64_t> RepairLatestPointer(const TableIdentifier& id);
};

[manuzhang]

Upstream status: not raised.

No matching issue or PR on apache/iceberg-cpp. Expected — this only becomes meaningful once a filesystem catalog (apache/iceberg-cpp#326, my #5) lands. Keep open as a downstream-of-#5 follow-up.

[manuzhang]

Correction — moot.

This issue presupposes the filesystem catalog (#5), which the Iceberg spec explicitly deprecates and slates for removal in v4 as "unsafe in object stores and local file systems". Repair tooling for a deprecated scheme isn't worth building.

Recommendation: close together with #5.