Refactor daily project management slack digest

[jimchamp]

Refactors existing daily project management digest workflow, removing the need for issue_comment_bot.py.

Technical

Testing

Screenshot

Stakeholders

[openlibrary-bot]

Took a look at this while scoping the "Issue Follower" sub-initiative under #13160 — this PR already covers most of that ground (event-driven Needs: Response labeling instead of the daily batch job), so rather than open a competing PR, a few concrete proposals here:

Blocking: missing config file

Both needs_response_labeler.yml and pm_new_comment_digest.yml read .github/workflows/config/new_comment_digest.json via fs.readFileSync(...), but it isn't part of this diff — as-is, both workflows will crash at runtime (file not found).

From how the fields are consumed in the diff, the shape needed is roughly:

{
  "leads": [
    { "githubUsername": "mekarpeles", "leadLabel": "Lead: @mekarpeles", "slackId": "U0XXXXXXX" },
    { "githubUsername": "cdrini", "leadLabel": "Lead: @cdrini", "slackId": "U0XXXXXXX" }
  ],
  "bots": [
    { "githubUsername": "openlibrary-bot", "triggersNeedsResponse": false },
    { "githubUsername": "dependabot[bot]", "triggersNeedsResponse": false },
    { "githubUsername": "renovate[bot]", "triggersNeedsResponse": false },
    { "githubUsername": "copilot-pull-request-reviewer[bot]", "triggersNeedsResponse": false }
  ]
}

slackId values need filling in by whoever has workspace access — not something derivable from the repo. leads presumably needs an entry per Lead: label currently in use, not just the two shown here.

Old digest workflow isn't retired

.github/workflows/new_comment_digest.yml (daily 08:30 cron, invokes scripts/gh_scripts/issue_comment_bot.py) still exists on master and isn't touched by this diff. Since the PR description says the goal is removing the need for issue_comment_bot.py, landing this as-is would leave both the old daily digest and the new pm_new_comment_digest.yml (08:45 cron) posting to Slack in parallel, and both the old script and the new real-time labeler attempting to apply Needs: Response. Worth having this PR also remove/deprecate new_comment_digest.yml (and the script, if nothing else calls it) so there's one system of record.

Good design choice worth keeping

Using an explicit bots config list (rather than checking GitHub's user.type/is_bot fields) to exclude bot accounts from triggering Needs: Response is the right call — we independently hit the same class of bug elsewhere this week: openlibrary-bot's account type is "User", not "Bot", so anything relying on user.type != 'Bot' silently fails to exclude it (see #13161, #13165). This design avoids that trap as long as openlibrary-bot (and the other bot accounts above) are actually listed once the config file lands.

Possible follow-on, not a blocker for this PR

needs_response_labeler.yml currently applies a blanket Needs: Response regardless of what the comment actually says. A natural v2 (separate PR, once this lands) could have an LLM-based pass read the comment and apply a more specific label where one clearly fits — e.g. an assignment request vs. a blocked/waiting question vs. a stalled-assignee check-in — rather than always defaulting to the same label. Flagging for later, not asking for it here.

Linking this to #13160 (Epic: AI Workflows) as the "Issue Follower" sub-initiative — no separate PAM PR planned for this as long as this one lands.

[jimchamp]

@openlibrary-bot's "Blocking: missing config file" section in the above message is not correct. The config file does indeed exist, and contains the appropriate configurations.

cc @mekarpeles

Edit: Also noting that the old daily digest workflow hasn't been removed b/c I'd like to compare the Slack messages that each workflow publishes. Once this workflow is producing the desired output, I'll delete the old digest.