Teach Copilot code review to flag missing localization

[adamint]

Is your feature request related to a problem?

Hardcoded user-facing strings can still be introduced in localized Aspire surfaces. We have clear localization patterns for the Dashboard, CLI, and VS Code extension, but this is easy to miss during review.

The existing automatic Copilot reviewer should be able to catch these without adding another agentic workflow that reads the same diff and leaves a second review.

Describe the solution you'd like

Add explicit path-specific Copilot review instructions for newly added or changed hardcoded user-facing strings:

• strengthen .github/instructions/dashboard.instructions.md
• add equivalent instructions for src/Aspire.Cli/**/*.cs
• add equivalent instructions for the relevant extension/src/** files and extension/package.json

GitHub's automatic reviewer consumes .github/instructions/. .agents/skills/code-review/SKILL.md is used for manual /code-review runs, so I think we should update that too and keep both review paths consistent.

The reviewer should flag high-confidence literals used as labels, tooltips, dialog text, notifications, prompts, help descriptions, progress text, or user-facing errors when they bypass the localization mechanism for that surface:

• Dashboard: use the appropriate resource-backed localizer and base .resx.
• CLI: use the appropriate resource .resx for output, prompts, help, and user-facing errors.
• VS Code extension: add code-displayed strings to both extension/src/loc/strings.ts and extension/package.nls.json; use %placeholder% entries for package.json contribution text.

It should not flag tests, docs, generated or translated files, protocol values, identifiers, URLs, telemetry, internal logs, or other clearly invariant/non-user-facing strings.

Acceptance criteria

• Copilot automatic review has explicit path-specific guidance for missing localization in Dashboard, CLI, and extension changes.
• The manual /code-review skill applies the same localization rubric.
• Findings are limited to added or changed user-facing strings and include the expected localization fix.
• Already-localized and non-user-facing literals do not receive findings.
• We do not add a second agentic PR reviewer for this.

[SankeerthNara]

Could you assign this to me