REST: Add data sequence number to scan tasks

[manuzhang]

Summary

• add optional data-sequence-number to REST-planned data files
• preserve manifest-entry data sequence numbers for Java data files while leaving delete-file JSON and file sequence numbers unchanged
• add content-file, scan-task, and REST scan-response regression coverage

Motivation

REST-planned scan tasks currently omit manifest-entry data sequence numbers. Row-lineage clients need the data file value to inherit a missing or null _last_updated_sequence_number and must not substitute a file or snapshot sequence number.

The field remains optional for rolling compatibility. Servers SHOULD include it when known for data files with a non-null first-row-id, while clients MUST NOT substitute a file or snapshot sequence number when it is absent. Scoping and emitting the new field only for row-lineage data files avoids changing ordinary data-file and delete-file payloads that do not need it for lineage inheritance.

This incorporates feedback from the broader content-file approach in #17234 by @wgtmac.

Compatibility

• New servers add an optional field only to row-lineage data-file payloads with non-null first-row-id; old clients are expected to ignore unknown fields.
• New clients continue to parse responses from old servers that omit the field and report unsupported lineage synthesis when the value is required.
• Delete-file JSON remains unchanged.

---

AI Disclosure

• Model: GPT-5
• Platform/Tool: Codex
• Human Oversight: reviewed
• Prompt Summary: Add backward-compatible REST data sequence number support for row-lineage data files.

[uros-b]

Well scoped and tested, thank you for this change @manuzhang!