[Improvement]: Migrate remaining table maintenance Executors to Process architecture

[zhangwl9]

Search before asking

• I have searched in the issues and found no similar issues.

What would you like to be improved?

PR #4116 extracted TableProcessStore from AmoroProcess and PR #4107 migrated SnapshotsExpiring to the new Process architecture. However, three table maintenance Executors still run on the legacy PeriodicTableScheduler infrastructure:

1. OrphanFilesCleaningExecutor — cleans orphan files via TableMaintainer.cleanOrphanFiles()
2. DataExpiringExecutor — expires data via TableMaintainer.expireData()
3. DanglingDeleteFilesCleaningExecutor — cleans dangling delete files via TableMaintainer.cleanDanglingDeleteFiles()

These Executors suffer from the same limitations that SnapshotsExpiringExecutor had before migration:

• No failure retry : exceptions are caught and logged only, never retried
• Dual scheduling logic : legacy InlineTableExecutors + new ActionCoordinatorScheduler coexist, increasing maintenance cost

How should we improve?

Migrate the four Executors to TableProcess implementations under IcebergProcessFactory,
following the pattern established by SnapshotsExpiringProcess.

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Subtasks

• [Improvement]: Refactor orphan-files-cleaning via ProcessFactory plugin #4208
• [Subtask]: Refactor dangling-delete-files-cleaning via ProcessFactory plugin #4216
• [Subtask]: Refactor DataExpiring via ProcessFactory plugin #4215
• [Subtask]: Remove invalid code and configuration about SnapshotsExpiringExecutor #4217

Code of Conduct

• I agree to follow this project's Code of Conduct

[zhangwl9]

@xxubai @baiyangtx @zhoujinsong I'd like to get your feedback on this proposal.As the main authors of AmoroProcess architecture, your input on the approach would be very valuable. Any thoughts or concerns are welcome.