IDE-323CI : fix artifact naming conflicts in reusable workflows

[harshsomankar123-tech]

Description

Jira Ticket: IDE-323

This PR resolves a critical CI pipeline failure where parallel emulator jobs (e.g., test-reports, coverage-report) were triggering (409) Conflict: an artifact with this name already exists errors. This issue was introduced following the migration to actions/upload-artifact@v4, which requires unique artifact names within a single workflow run.

By replacing the dynamic ${{ github.job }} reference—which resolved to the same internal ID within the reusable emulated_tests.yml—with unique string literals passed as inputs for each job (e.g., instrumented-unit-tests, rtl-tests), I have ensured that artifacts are correctly uploaded to distinct folders. This satisfies the acceptance criteria of ensuring the CI pipeline completes without 409 errors and that artifacts are easily identifiable in the GitHub Actions summary.

Your checklist for this pull request

Please review the contributing guidelines and wiki pages of this repository.

• Include the name of the Jira ticket in the PR’s title
• Include a summary of the changes plus the relevant context
• Choose the proper base branch (develop)
• Confirm that the changes follow the project’s coding guidelines
• Verify that the changes generate no compiler or linter warnings
• Perform a self-review of the changes
• Verify to commit no other files than the intentionally changed ones
• Include reasonable and readable tests verifying the added or changed behavior
• Confirm that new and existing unit tests pass locally
• Check that the commits’ message style matches the project’s guideline
• Stick to the project’s gitflow workflow
• Verify that your changes do not have any conflicts with the base branch
• After the PR, verify that all CI checks have passed
• Post a message in the catroid-stage or catroid-ide Slack channel and ask for a code reviewer

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[reichli]

Looks good - PR has my approval :)

I looked through the generated reports. Test reports look good, but the coverage reports show 0% everywhere.
But this can be addressed in a follow-up ticket - I suggest we merge this PR.

[ratschillerp]

LGTM