refactor: use shared slack-notification action [skip ci]

[MishaKav]

Summary

Use the slack-notification composite action from shared-workflows.

JIRA: https://linearb.atlassian.net/browse/LINBEE-20794

🤖 Generated with Claude Code

✨ PR Description

Purpose: Replace external Slack notification action with internal shared workflow to standardize notification format and consolidate implementation.
Main changes:

• Replaced rtCamp/action-slack-notify with linear-b/shared-workflows/.github/actions/slack-notification
• Consolidated success and failure notifications into a single conditional action
• Simplified message format while preserving release information and links

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Description using Guidelines Learn how}

[orca-security-us]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Infrastructure as Code	0   0   0   0	View in Orca
Passed	SAST	0   0   0   0	View in Orca
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[gitstream-cm]

✨ PR Review

The refactoring consolidates two separate notification steps into one shared action, which improves maintainability. However, there are concerns about using an unstable branch reference and handling of non-standard job statuses.

2 issues detected:

🧹 Maintainability - Using a branch reference instead of a stable version tag creates unpredictable behavior and potential breaking changes.

Details: The workflow references the shared action using '@develop' branch instead of a stable tag or version. This creates non-deterministic builds where changes to the develop branch could unexpectedly break this workflow without warning. It also makes it harder to track which version of the action is being used and violates GitHub Actions best practices.
File: .github/workflows/create-tag-on-merge.yml

🐞 Bug - Cancelled jobs will display 'Failed to release' which is technically inaccurate and could cause confusion. 🛠️

Details: The notification uses 'always()' condition which means it will run even when the job is cancelled. However, the message only distinguishes between 'success' and any other status, displaying 'Failed to release' for cancelled jobs. This differs from the previous behavior where no notification was sent on cancellation.
File: .github/workflows/create-tag-on-merge.yml (129-129)
_{🛠️ A suggested code correction is included in the review comments.}

Generated by LinearB AI and added by gitStream.
_{AI-generated content may contain inaccuracies. Please verify before using.
💡 Tip: You can customize your AI Review using Guidelines Learn how}

[gitstream-cm]

🐞 Bug - Inaccurate Message: Add explicit handling for the 'cancelled' status in the message, or change the condition from 'always()' to '(success() || failure())' to match the previous behavior.

Suggested change

	${{ job.status == 'success' && 'Released' || 'Failed to release' }} `${{ env.NEW_TAG }}` to `gitstream-github-action`
	${{ job.status == 'success' && 'Released' || (job.status == 'cancelled' && 'Cancelled release of' || 'Failed to release') }} `${{ env.NEW_TAG }}` to `gitstream-github-action`

Is this review accurate? Use 👍 or 👎 to rate it

If you want to tell us more, use /gs feedback e.g. /gs feedback this review doesn't make sense, I disagree, and it keeps repeating over and over