This appears to fail with the new GitHub background tasks type

[Azuka]

Describe the bug
GitHub recently released support for background tasks and running in parallel.

This action fails when trying to resolve ids from a parallel wait

To Reproduce
Steps to reproduce the behavior:

1. create a workflow with parallel tasks
2. This action fails to read the steps on the nested parallel wait
3. See error

Run act10ns/slack@v2
  with:
    status: success
    message: Deployed successfully to...
  
    steps: {
    "__parallel_0_0": {
      "outputs": {
        "aws-account-id": "...",
        "authenticated-arn": "..."
      }
    },
    "__parallel_0_1": {
      "outputs": {
        "helm-path": "/opt/hostedtoolcache/helm/3.17.3/x64/linux-amd64/helm"
      }
    },
    "__parallel_0_2": {
      "outputs": {
        "kubectl-path": "/opt/hostedtoolcache/kubectl/1.36.2/x64/kubectl"
      }
    },
    "Parallel group": {
      "outputs": {},
      "outcome": "success",
      "conclusion": "success"
    }
  }
    config: .github/slack.yml
  env:
    FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
    SLACK_WEBHOOK_URL: ****
Reading config file .github/slack.yml...
(node:2215) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Error: Cannot read properties of undefined (reading 'toLowerCase')

Expected behavior
No failure.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

[Yunczo]

I traced the exact exception to src/slack.ts, before the webhook call.

namedSteps currently removes only 32-character hex auto-IDs, so the new parallel pseudo-steps such as __parallel_0_0 remain. Those entries contain outputs but no outcome. The default Job Steps field then evaluates {{icon this.outcome}}, and stepIcon(undefined) calls status.toLowerCase(), which matches the reported error exactly. The real Parallel group entry has outcome: "success" and is not the problem.

A focused repair would keep only renderable step records and make the helper defensive:

const namedSteps = Object.fromEntries(
  Object.entries(jobSteps).filter(
    ([key, value]) =>
      !/^[0-9a-f]{32}$/.test(key) &&
      typeof (value as {outcome?: unknown} | null)?.outcome === 'string'
  )
)

function stepIcon(status: unknown, opts?: IconOptions): string {
  const normalized = typeof status === 'string' ? status.toLowerCase() : ''
  // compare normalized below; fall back to the default icon for anything else
}

I would add the steps JSON from this report as a regression fixture and assert that the three __parallel_* records are excluded while Parallel group still renders with the success icon.