feat: post nightly-release Slack notifications via a Workflow Builder trigger - W-24443946

[madhur310]

Summary

• IDEE_MAIN_SLACK_WEBHOOK is dead: posting to it returns {"ok":false,"error":"webhook_not_found"} (404). This meant vscode-publish-extensions.yml's slack-notify (success) and slack-notify-failure jobs have likely been silently failing to post for every consumer in non-dry-run runs.
• Initial fix in this PR swapped to IDEE_RELEASE_SLACK_WEBHOOK (confirmed alive) as a stopgap, but that channel turned out to be unmonitored/unused.
• Final fix: both Slack jobs now post directly to a dedicated Slack Workflow Builder webhook trigger via curl, instead of slackapi/slack-github-action with a classic incoming-webhook Block Kit payload. That trigger's payload contract is a flat set of variables, not a free-form message, so the "Notify Slack" steps were rewritten to build:

  {
    "status": "success|failure",
    "error_details": "... (which job failed, empty on success)",
    "run_url": "https://github.com/<repo>/actions/runs/<run_id>",
    "registries": "...",
    "extension_names": "...",
    "versions": "...",
    "release_type": "Pre-release|Stable"
  }

• New secret IDEE_NIGHTLY_RELEASE_WEBHOOK holds the trigger URL, set as a repo-level secret on all three current consumers (salesforcedx-vscode, apex-language-support, salesforcedx-vscode-ci-testing) since they all call this reusable workflow with secrets: inherit.
• Dropped the now-dead slack-notification-title input (only used by the removed Block Kit payload; no caller passed it explicitly).

Known gap

forcedotcom/b2c-dx's publish-vscode.yml references IDEE_MAIN_SLACK_WEBHOOK directly in its own file, independent of this reusable workflow — this PR doesn't fix that call site.

Test plan

• Not live-tested against this reusable workflow directly (would require a real nightly-release/publish run against a consumer repo). Confidence comes from verifying the new trigger's schema and curl payload shape against the equivalent, already-live-tested pattern in forcedotcom/salesforcedx-vscode PR #8379.

[mshanemc]

if this is meant as a generic workflow to publish extensions, the secret could just be named
"SLACK_WEBHOOK" and then consumers could put whatever value there. It doesn't have to match the name of the secret stored in github.

[madhur310]

Good point, done — renamed to SLACK_WEBHOOK: 2d43c37fb. Since the three current callers use secrets: inherit rather than explicit secret mapping, I renamed the actual stored secret in all three consumer repos (salesforcedx-vscode, apex-language-support, salesforcedx-vscode-ci-testing) from IDEE_NIGHTLY_RELEASE_WEBHOOK to SLACK_WEBHOOK to match, rather than switching them to explicit mapping.

[mshanemc]

approved pending comment resolution