fix: reject timeout_minutes on reusable-workflow callbacks

[joshua-temple]

Problem

A per-callback timeout_minutes on a build, deploy, or validate callback produced an invalid workflow. cascade callbacks are reusable-workflow only, so every callback is emitted as a jobs.<id>.uses caller job. Config validation did not reject timeout_minutes, and the retry-shim emit path still wrote a timeout-minutes: line on the uses: job, so generation could silently emit YAML that GitHub rejects at parse time.

GitHub Actions semantics

A job that calls a reusable workflow (jobs.<id>.uses) may only set: uses, with, secrets, needs, if, permissions, strategy, name, and concurrency. timeout-minutes is forbidden on such a job; it must be declared inside the called workflow. This rule was already documented in the codebase for the main caller job and for runs_on/concurrency; timeout_minutes was the missing case.

Fix

• Validation now rejects per-callback timeout_minutes on reusable-workflow callbacks (builds, deploys, validate) via a new validateCallbackTimeout, mirroring the existing runs_on/concurrency rejection. The error points the operator to set timeout-minutes inside the callback workflow.
• The generator no longer emits timeout-minutes: on the retry-shim uses: job. The TimeoutMinutes field is kept on CallbackInfo as validated-against-but-never-emitted, matching how runs_on/concurrency are handled.
• The manifest-level job_timeout_minutes (cascade-owned job timeout) is unchanged and still emitted on owned jobs.

Verification

• go build ./...: success
• go test ./...: 1355 passed in 23 packages
• go vet ./...: no issues
• golangci-lint run ./...: no issues
• New table-driven tests: rejection for build/deploy/validate callbacks, plus control cases (callback without timeout, and manifest-level job_timeout_minutes) that must stay clean.

Do not merge yet.