jobs plugin: named/multiple jobs crash-loop at startup (manifest hardcodes `DATABRICKS_JOB_ID`)

[philip]

Summary

When the jobs plugin is configured with a named job, the app fails to start: it reports DATABRICKS_JOB_ID as a missing required resource, even though only named jobs (e.g. DATABRICKS_JOB_ETL) were configured. A single unnamed job bound to DATABRICKS_JOB_ID starts as expected.

Version

@databricks/appkit v0.63.0 (git 62451912) · Databricks Apps (also reproduces locally via createApp).

Reproduction

import { createApp, jobs } from '@databricks/appkit';

createApp({ plugins: [jobs({ jobs: { etl: {} } })] });
// env: DATABRICKS_JOB_ETL=<id>   (DATABRICKS_JOB_ID unset)

Expected: the app boots with an etl job accessor.
Actual: startup fails with a missing-required-resources error naming DATABRICKS_JOB_ID.

Root cause

The jobs plugin declares its job resource twice, and the two disagree:

• Static: plugins/jobs/manifest.json hardcodes DATABRICKS_JOB_ID as required (resourceKey: "job").
• Dynamic: JobsPlugin.getResourceRequirements() (plugins/jobs/plugin.ts:132) emits DATABRICKS_JOB_<NAME> per job (job-<name>; the default key → DATABRICKS_JOB_ID).

ResourceRegistry.collectResources (registry/resource-registry.ts) registers both — the static required loop near line 106 and the dynamic loop near line 118. The mismatched keys (job vs job-<name>) never merge, so a named-jobs app is left with an unsatisfiable static DATABRICKS_JOB_ID requirement. The single-default case works only because its dynamic env is also DATABRICKS_JOB_ID.

serving and files share this static-plus-dynamic pattern but escape the crash by reusing the static env var; jobs can't, since named jobs derive DATABRICKS_JOB_<NAME>.

Separately, appkit plugin sync resolves only the static manifest.json (getResourceRequirements is unused in the CLI), so appkit.plugins.json is blind to named jobs too.

Suggested fix (via Claude)

Drop the hardcoded required job from plugins/jobs/manifest.json (resources.required: []) and let getResourceRequirements() be the single source of truth — it already maps default → DATABRICKS_JOB_ID, so the single-default case keeps working and named jobs stop demanding a phantom DATABRICKS_JOB_ID.