ECHOES-1311 Pass brand value to build step in unified dogfooding workflow

[david-cho-lerat-sonarsource]

The build step in the unified dofgooding workflow is missing the now-mandatory brand value.
Also, the sonar-s-public runners have been deprecated in favor of sonar-s, which can now handle public repositories.

A run of the dogfooding workflow on this PR's branch shows that it works: https://github.com/SonarSource/echoes-react/actions/runs/25716453852

[netlify]

✅ Deploy Preview for echoes-react ready!

Name	Link
🔨 Latest commit	b814a94
🔍 Latest deploy log	https://app.netlify.com/projects/echoes-react/deploys/6a02c2d75ae233000852b490
😎 Deploy Preview	https://deploy-preview-687--echoes-react.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[hashicorp-vault-sonar-prod]

ECHOES-1311

[sonar-review-alpha]

Summary

This PR updates CI/CD workflows to support design token branding in the unified dogfooding pipeline. It makes two key changes:

1. Runner migration: Both build.yml and unified-dogfooding.yml now run on the internal sonar-s runner instead of sonar-s-public
2. Brand environment variable: The build-yarn step in the unified dogfooding workflow now receives DESIGN_TOKEN_BRAND: Brand-A, allowing the build to consume brand-specific design tokens

The env var addition is the feature work; the runner change appears to enable or accompany that feature.

What reviewers should know

Where to look:

• The substantive change is the new env: block (lines 23-24) in unified-dogfooding.yml — this is what enables brand values to be passed downstream
• The runner change is consistent across both workflows, suggesting it's a coordinated infrastructure update

Things to verify:

• Does DESIGN_TOKEN_BRAND: Brand-A match what downstream build/scan steps expect?
• Is the runner change intentional for both workflows, or just needed for the unified dogfooding job?
• Check if the internal sonar-s runner has necessary permissions/access that sonar-s-public lacks

Note: The PR description is empty — context about the ECHOES-1311 ticket would help clarify the intent and impact of the runner migration.

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[sonar-review-alpha]

LGTM! ✅

Straightforward and correct fix. The DESIGN_TOKEN_BRAND env var is required by design-tokens/build.js (it calls process.exit(1) when missing), so the unified dogfooding workflow was broken before this PR. The value Brand-A matches what build.yml already uses, which is consistent.

The runner migration from sonar-s-public to sonar-s in both workflows appears intentional and consistent.

🗣️ Give feedback

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
No data about Duplication

See analysis details on SonarQube