chore(CI): add slack notifications

[rishav-karanjit]

Issue #, if available:

Description of changes:

Adding slacking notification on daily CI failure and issue creation.

Similar PR in DB-ESDK: aws/aws-database-encryption-sdk-dynamodb#1964

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Check any applicable:

• Were any files moved? Moving files changes their URL, which breaks all hyperlinks to the files.

To fix the problem, explicitly declare permissions so the GITHUB_TOKEN used by this workflow is restricted to the minimum needed. Since this workflow only reacts to issues and issue comments and sends notifications to Slack via a reusable workflow, it does not need write access to repository contents or other resources. The minimal safe configuration is to set permissions: { contents: read } at the workflow root, which ensures read-only access to repo contents while still allowing GitHub to expose the issue/comment event payload to the workflow. If the reusable workflow needs more (for example, issues: write), it can be requested there; from the caller’s perspective we keep things as tight as possible without changing any functional behavior.

Concretely:

• Edit .github/workflows/issue-notification.yml.
• Add a permissions: block right after the name: line (before on:) so it applies to all jobs.
• Set contents: read as a minimal, least-privilege default. We are not changing any jobs, conditions, or secrets handling.

No additional imports or methods are needed, because this is a YAML configuration change only.

To fix the problem, explicitly set permissions for this workflow to the minimum required. These jobs only read issue and comment metadata to build Slack messages and do not need write access to the repository or issues. The safest general approach is to add a top-level permissions block (so it applies to both jobs) with read-only access to repository contents. If the reusable workflow needs additional scopes, they can be added there, but we should start from a restrictive baseline.

The single best change, without altering existing functionality, is to add at the root level of .github/workflows/issue-notification.yml a block such as:

permissions:
  contents: read

placed after the name: (or after the on: block—both are valid as long as it’s top-level). This will ensure the GITHUB_TOKEN has only read access to repository contents unless further narrowed or expanded in the called reusable workflow. No imports or additional methods are needed; it is purely a YAML configuration change.

Concretely: in .github/workflows/issue-notification.yml, insert a new permissions: block between the existing on: section and the jobs: section (around line 8), leaving all other lines unchanged.