feat(plugin-workers): generated registry cannot consume project job policy metadata

[rickylabs]

Important

0.0.7 seam decision. The single project-authored source is the existing
netscript.config.ts workers configuration (workers.groups[].jobs[]), already consumed by Windows
runtime overrides. The config package must type and validate the full job policy; the installed workers
registry generator consumes that validated data and emits both runtime handlers and
RegisterJobInput definitions. No second manifest or hand-edited generated file is introduced.
External equivalence evidence is pinned to EIS-Chat commit
5191de83f3da97559f21d8891c6c8afdf1cf473a.

Consumer evidence

EIS-Chat migration to NetScript 0.0.5 found that the generated worker registry is the effective runtime authority, but project-owned operational metadata cannot be supplied through one supported source consumed by both workers-api and the background runtime.

The application needs per-job descriptions, timeout (120s), retries/retry delay, concurrency, tags, persistence/priority/topic, and explicit Deno permissions. The old local workers/job-definitions.ts shim had zero consumers, while runtime-registry-generator.ts emits fixed generic values (including a 300000ms timeout).

Impact

Consumers must choose between:

• editing generated output,
• maintaining an inert policy file that looks authoritative but is not, or
• silently accepting generic runtime policy.

EIS-Chat deleted the inert shim and records the desired policy as upstream drift; it does not claim the generic defaults are equivalent.

Acceptance

• One documented project metadata/config seam is consumed by workers-api and startCombinedProcess().
• Generated registries preserve project descriptions, timeout, retry policy, concurrency, tags, persistence/priority/topic, and permissions.
• A scaffold/runtime integration test proves the effective definitions match project input without hand-editing generated files.