test(bundle): drive the cron dispatcher's unknown-job arm through dist/index.js

[hivecommons-hive]

Test Improvement

Adds the two cases #242 left out of __tests__/bundle/cronJobsInput.test.ts, driving src/cronJobs/handleCronJob.ts' default arm (could not execute <name>. May not be supported - please refer to docs, line 55) through the committed dist/index.js:

• jobs: 'Tide' on workflow_dispatch → exit 1, the error names tide (lowercased), gh.requests empty
• jobs: 'bogus\nlabel-sync' on schedule → exit 1 naming bogus, while label-sync still completes beside it (configuration reads, GET /labels, built-in label POSTs and its summary line)

Evidence on main @ c18e968: npm run test:coverage:e2e (22 files / 214 tests) reported handleCronJob.ts 95.45 % lines with line 55 the only miss; this file's run under the coverage bundle now hits it. Unit coverage of the arm was already 100 % (__tests__/cronJobTest/handleCronJob.test.ts).

Files: __tests__/bundle/cronJobsInput.test.ts only. The could not execute matches in held #310 and #357 are the pull-request and issue-comment dispatchers, not the cron one.

Related Issue

Closes #241

---

Filed by quality agent (hold-gated mode). Human review required.

— hive: agent=quality backend=copilot model=claude-fable-5.1 copilot=1.0.88

[hivecommons-hive]

Important

Held for human review by the hive's ACMM level gate.

This PR was opened by the "quality" agent while Hive policy required a human checkpoint for that agent. Non-outreach agents are held at ACMM L3–L5; the outreach agent is always held because it publishes project-facing communication.

Hive will keep the hold label until a human removes it. Operators can make a deliberate one-off release during an ACMM level change with release_level_holds=true, but level changes never release this hold automatically.

[jeefy]

The first case is worth keeping: it reaches the unknown-job branch at handleCronJob.ts:55, which no other test does. Two changes:

• cronJobsInput.test.ts, first case: check a fragment, e.g. expect(result.errors).toHaveLength(1) plus errors[0] includes could not execute tide, instead of comparing the whole TypeError: error handling cron job: Error: … string with toEqual.
• Drop the second case (bogus\nlabel-sync). It reaches nothing the first case doesn't, and label-sync itself is already covered in bundle.test.ts. #242 dropped the same case for the same reason.

[hivecommons-hive]

Addressed both: the first case now checks errors has length 1 and that errors[0] contains could not execute tide, and the bogus\nlabel-sync case is dropped (the unused configReads/repo imports went with it). Merged main as well. npx vitest run __tests__/bundle/cronJobsInput.test.ts: 3/3 pass.

---

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5q9t | SHA: ca28871

— hive: agent=quality backend=copilot model=claude-fable-5.1

[hivecommons-hive]

Addressed in ca28871: the unknown-job case checks toHaveLength(1) + a could not execute tide fragment, and the bogus\nlabel-sync case is dropped.

CI is green on the new head.

---

🐝 Hive Agent: quality | Instance: hosted-available-lke648397-260827-5q9t | SHA: 1f7d33c

— hive: agent=quality backend=copilot model=claude-fable-5.1 copilot=1.0.88

[jeefy]

Asks addressed; verified on current main (aa6a0f8) together with the other approved PRs.

[jeefy]

/kind cleanup
/lgtm
/approve
/hold cancel