fix(ci): Lint Commits fails at startup so commit policy is unenforced

[ss-o]

Summary

The Lint Commits workflow has never run successfully. Every recent pull
request into main records startup_failure, so the commit-message,
PR-title, and branch-name policy it enforces is not actually being applied in
this repository.

Evidence

PR head branch	Lint Commits result
code/promotion-precondition-ancestry (#574)	startup_failure
code/issue-452-renovate-tuning (#572)	startup_failure
code/adr-0021-chroma-runtime (#571)	startup_failure
bug-568 (#570)	startup_failure

gh api repos/z-shell/.github/actions/runs/33292356089 --jq '{conclusion,path}'
{"conclusion":"startup_failure","path":".github/workflows/lint-commits.yml"}

GitHub reports This run likely failed because of a workflow file issue. A
startup_failure means the run never began, so no job inside it executed and
no policy check was evaluated.

Why this matters

commit-lint.yml is the mechanical enforcement of the AGENTS.md ban on bot and
AI-agent Co-authored-by trailers, the Conventional Commits rule from
ADR-0003, and the issue-linked branch naming from ADR-0019. AGENTS.md states
that z-shell/.github and z-shell/zi enforce the trailer ban in CI.

In z-shell/zi that is true: PR z-shell/zi#462 shows Validate Commits,
Validate PR Title, and Validate Branch Name all reporting SUCCESS. In
this repository the same policy is silently inert.

This is the failure mode the organization policy warns about: a rule that
exists only as text where a mechanism was believed to be enforcing it. The
local scripts/git-hooks/commit-msg hook still strips the trailer for
contributors who have configured core.hooksPath, but that is per-clone and
is not a substitute for the server-side gate.

Suspected cause

lint-commits.yml calls the local reusable workflow:

jobs:
  commit-lint:
    uses: ./.github/workflows/commit-lint.yml

commit-lint.yml declares permissions: {} at workflow level and then sets
job-level permissions: blocks. The exact rejection has not been confirmed,
and the run produces no job logs to read, so the cause needs to be reproduced
rather than assumed. Candidate areas to check first:

1. whether the caller satisfies every required input and permission the
   reusable workflow declares, given the top-level permissions: {};
2. whether the on: workflow_call input defaults containing regular
   expressions with backslashes parse cleanly; and
3. whether the reusable workflow reference resolves for a pull_request event
   from a same-repository branch.

Suggested verification

Once fixed, confirm on a real pull request that all three job contexts appear
and pass, then consider adding them to the main ruleset's
required_status_checks, which currently requires no contexts at all:

gh api repos/z-shell/.github/rulesets/19646747 --jq '[.rules[]|select(.type=="required_status_checks")]'
[]

A workflow that cannot start and a ruleset that requires nothing means neither
layer is currently gating merges into main.

Scope

Found while working on #573. Reported rather than fixed, since it is unrelated
to that change.