[spark] Record the write operation type in snapshot properties

[Zouxxyy]

Purpose

Add a first-class operation field (Snapshot.Operation enum) to Snapshot, recording the logical operation type that produced it. This complements the physical CommitKind (APPEND/COMPACT/OVERWRITE/ANALYZE) and lets downstream tooling distinguish, e.g., an APPEND from INSERT vs. one from MERGE.

Design:

• Snapshot.Operation enum: WRITE, OVERWRITE, DELETE, TRUNCATE, UPDATE, MERGE, CREATE_TABLE_AS_SELECT, REPLACE_TABLE_AS_SELECT, CREATE_OR_REPLACE_TABLE_AS_SELECT
• Nullable field with @JsonInclude(NON_NULL) — old snapshots deserialize as null, old readers ignore the unknown field via @JsonIgnoreProperties(ignoreUnknown = true)
• BatchTableCommit.withOperation(Operation) — default method, no breaking change for existing implementations
• FileStoreCommit.withOperation(Operation) — internal API, propagated to Snapshot construction in FileStoreCommitImpl
• TRUNCATE is automatically set by TableCommitImpl.truncateTable()/truncatePartitions() in core, so callers don't need to handle it

Spark coverage (both v1 and v2 write paths):

SQL	operation
INSERT INTO	WRITE
INSERT OVERWRITE	OVERWRITE
DELETE (row-level)	DELETE
DELETE (full-table / partition)	TRUNCATE
TRUNCATE TABLE	TRUNCATE
UPDATE	UPDATE
MERGE INTO	MERGE
CREATE TABLE AS SELECT	CREATE_TABLE_AS_SELECT
(CREATE OR) REPLACE TABLE AS SELECT	REPLACE_TABLE_AS_SELECT / CREATE_OR_REPLACE_TABLE_AS_SELECT

Tests

• SnapshotTest.testSnapshotWithOperation (paimon-core): JSON serialization round-trip, backward compatibility with old snapshots
• SnapshotOperationTest (paimon-spark-ut): all operations under both use-v2-write=true/false, including CTAS/RTAS and truncate paths

[JingsongLi]

I think adding operation as a dedicated nullable field in Snapshot is a better direction than storing it in properties.
The parsing overhead should be negligible. Snapshot metadata is already read and deserialized as JSON, so one additional nullable string/enum field will not have meaningful performance impact compared with filesystem IO and manifest planning. With @JsonInclude(NON_NULL), old snapshots and snapshots without operation will not carry extra JSON size either.

Compatibility should also be fine:

• Old snapshots do not have this field, so the new reader can treat it as null.
• Older readers should ignore the new field because Snapshot already uses @JsonIgnoreProperties(ignoreUnknown = true).

I would suggest modeling it as a first-class nullable enum or string field, for example Snapshot.Operation, rather than putting it into properties. commitKind describes the physical snapshot change, while operation describes the logical user operation, so both feel like core snapshot metadata.

This would also avoid introducing a generic withCommitProperties API just for one standard field, and avoids potential conflicts around the "operation" property key.

[JingsongLi]

replaceManifestList is used by maintenance/repair flows such as row-id reassignment and removing broken manifests, but this copies the previous snapshot's logical operation into the new maintenance snapshot. That makes the $snapshots.operation value look like the previous user operation even though this snapshot was produced by a manifest rewrite. I think this should stay null (or use a dedicated maintenance operation) instead of inheriting latest.operation(); the same concern applies to the manifest compaction snapshot below.

[JingsongLi]

Thanks for restoring the no-version constructor overload. The versioned public constructor is still source/binary incompatible because the old Snapshot(int version, ..., Long nextRowId) signature was replaced by the new one that requires operation. Since Snapshot is @Public, could we also keep that old versioned overload and delegate to this constructor with operation = null?