feat(create-issues-from-todos): support client-id, deprecate app-id

[devantler]

🤖 Generated by the Daily AI Assistant

What

Add a client-id input to the create-issues-from-todos composite action and mark app-id as a deprecated alias. Both are wired through to actions/create-github-app-token; callers pass exactly one.

Why

actions/create-github-app-token has deprecated the app-id input in favour of client-id (its action.yml: app-id … deprecationMessage: "Use 'client-id' instead."). Every token-minting job that still passes app-id emits:

Input 'app-id' has been deprecated with message: Use 'client-id' instead.

Non-failing today, but deprecated inputs are eventually removed upstream — at which point the job breaks. This is the root-cause unblock for the remaining piece of reusable-workflows #308: scan-for-todo-comments.yaml passes app-id to this composite, so the rw caller can only switch to client-id once the composite accepts it. The org already exposes vars.APP_CLIENT_ID alongside vars.APP_ID, so no provisioning is needed.

Approach — additive & backward-compatible (blast-radius first)

Per the repo's "prefer additive, keep an alias where feasible" guidance, this is not a breaking rename:

• New optional client-id input (preferred).
• app-id kept as an optional, deprecated alias (was required: true → required: false).
• Both forwarded to create-github-app-token; a caller supplies exactly one, the empty one is ignored.
• app-private-key stays required (needed for either ID).

Existing app-id callers keep working unchanged (they just keep emitting the upstream warning until they migrate). The composite's own CI self-test (test-create-issues-from-todos) is switched to client-id to exercise the preferred path end-to-end and drop the warning in this repo's CI.

Validation

• actionlint .github/workflows/ci.yaml → no new findings (only pre-existing code-quality permission-scope warnings, unrelated).
• Composite action.yaml YAML structure verified; token step forwards both inputs.
• README input table + usage examples updated to client-id / vars.APP_CLIENT_ID with a footnote on "exactly one".

Follow-up (separate, gated on this release + repin)

Once released and repinned in reusable-workflows, switch scan-for-todo-comments.yaml app-id → client-id to close out #308's composite-path remainder. (run-dotnet-tests.yaml's stale app-id/app-private-key inputs are a separate cleanup — that composite no longer mints a token.)

🤖 Generated with Claude Code

[github-code-quality]

Code Coverage Overview

Languages: Go, C#

Go / code-coverage/test

The overall coverage remains at 50%, unchanged from the main branch.

C# / code-coverage/dotnet

The overall coverage remains at 100%, unchanged from the main branch.

---

_{Updated June 10, 2026 14:24 UTC
Code Coverage is in Public Preview. Learn more and provide us with your feedback.}

[devantler]

🤖 Generated by the Daily AI Assistant

Note on the failing zizmor code-scanning check (advisory, not a merge gate): it reports one github-app alert at create-issues-from-todos/action.yaml:21 — "app token inherits blanket installation permissions". This is not introduced by this PR: it's the repo's pre-existing app-token pattern (the same rule also fires on the untouched approve-pr/action.yaml:25, and main has no open alert only because those lines weren't recently scanned). Touching the app-token step's lines re-attributed it as "new in changed code".

It is advisory — CI - Required Checks (the only required status check on main) is green, so this does not block. Fixing it properly means scoping each create-github-app-token call to least-privilege permission-* inputs, which needs per-action permission analysis + runtime validation to avoid silently breaking the scheduled TODO scanner's Projects write — out of scope for this client-id migration. Tracked as a dedicated security item in #274.

[devantler]

🤖 Generated by the Daily AI Assistant

This PR is mergeStateStatus: BLOCKED not because of anything in its own diff — required CI - Required Checks is green — but because main's code-scanning baseline is frozen at 2025-07-17 with 9 phantom zizmor alerts on a since-deleted workflow file (reusable-workflow-ci-gitops-test.yaml), and the code_scanning branch rule counts them as a merge blocker on every PR.

Root cause + fix is in #275 (the zizmor job was gated off for push events, so the default-branch baseline never refreshed). Dismissing those 9 stale alerts once — or merging #275 — clears the block here too.