direct: job with a table_update trigger never converges — trigger.table_update.condition is input-only and not registered as such

[ajheunis]

Summary

On the direct deployment engine, a job with a table_update trigger that sets
condition never converges. Every bundle plan after a successful
bundle deploy reports 1 to change, forever.

The Jobs API accepts trigger.table_update.condition on create/update but never
returns it from GET /api/2.2/jobs/get. condition is therefore an input-only
field, and it is not registered as one, so the direct engine diffs it against a
missing remote value and plans an update on every run.

This is the same class of bug as #6076 (allow_duplicate_names on pipelines)
and the webhook_notifications.on_* phantom diff fixed in #6060. It is not
fixed in v1.11.0.

CLI version

v1.10.0 (also reproduces the same way before a resource rename, so it is not
name-related).

Repro

resources:
 jobs:
 render_files:
 name: render_files
 trigger:
 table_update:
 table_names:
 - main.default.some_table
 condition: ANY_UPDATED
 wait_after_last_change_seconds: 60
 tasks:
 - task_key: t
 notebook_task:
 notebook_path: ../src/nb.ipynb
 environment_key: default
 environments:
 - environment_key: default
 spec:
 environment_version: "4"

databricks bundle deploy -t dev # succeeds
databricks bundle plan -t dev # Plan: 0 to add, 1 to change, 0 to delete
databricks bundle deploy -t dev # succeeds
databricks bundle plan -t dev # Plan: 0 to add, 1 to change, 0 to delete

Evidence

bundle plan -t dev --output json, plan["resources.jobs.render_files"]:

"changes": {
 "trigger.table_update.condition": {
 "action": "update",
 "old": "ANY_UPDATED",
 "new": "ANY_UPDATED"
 }
}

old and new are identical and the action is still update. old comes from
the bundle's own saved state (state/resources.json), which records:

"trigger": {
 "pause_status": "PAUSED",
 "table_update": {
 "condition": "ANY_UPDATED",
 "table_names": ["<catalog>.<schema>.matched_files"],
 "wait_after_last_change_seconds": 60
 }
}

while remote_state in the same plan — and the raw
GET /api/2.2/jobs/get?job_id=... — has no condition at all:

"trigger": {
 "pause_status": "PAUSED",
 "table_update": {
 "table_names": ["<catalog>.<schema>.matched_files"],
 "wait_after_last_change_seconds": 60
 }
}

Two sibling jobs in the same bundle with file_arrival triggers, and a pipeline,
all report as unchanged; only the job with table_update + condition drifts.

Expected

trigger.table_update.condition should be treated as an input-only field so the
plan converges, the same way #6076 handled allow_duplicate_names.

Workaround

Omit condition from the bundle config. Where a trigger names a single table,
ANY_UPDATED and ALL_UPDATED are equivalent, so this costs nothing there — but
it is not an option for a multi-table trigger that needs ALL_UPDATED.