Investigate making visually confusable Unicode distinguishable in the dashboard

## Summary

The dashboard renders resource names and other externally supplied identifiers and values as Unicode text. Different strings can look identical or nearly identical to a user. For example:

- `api` and `аpi`, where the first character of the second value is U+0430 CYRILLIC SMALL LETTER A rather than U+0061 LATIN SMALL LETTER A
- `orders` and a visually identical value whose code points are `U+006F U+0072 U+200B U+0064 U+0065 U+0072 U+0073`, including U+200B ZERO WIDTH SPACE
- canonically equivalent composed and decomposed sequences, such as U+00E9 versus U+0065 U+0301
- text containing bidirectional control characters that renders in a different order from its underlying code points

This can make it difficult to select, correlate, and troubleshoot the correct resource. It could also disguise accidental or malicious external data. We should investigate how the dashboard can preserve the original value while making these distinctions discoverable.

## Prior art

- [GitHub warns when files contain bidirectional Unicode text](https://github.blog/changelog/2021-10-31-warning-about-bidirectional-unicode-text/) and directs users to inspect the hidden characters. The warning is targeted rather than changing the stored content.
- [Unicode Technical Standard #39](https://www.unicode.org/reports/tr39/) defines confusable detection, mixed-script detection, identifier restriction levels, and data for visually confusable characters. It also notes that detection can be overly inclusive and that confusable skeletons are for comparison, not display.

## Investigation questions

- Which externally supplied dashboard data should be covered initially? Resource names, replica/instance IDs, endpoint names, selectors, telemetry attributes, and arbitrary log text have different signal-to-noise tradeoffs.
- Which cases should always be surfaced, such as bidi controls, zero-width/default-ignorable characters, and unusual whitespace?
- Should visual confusables and mixed scripts be flagged only when two values in the same context collide, or whenever a value is potentially ambiguous?
- Should canonically equivalent strings be treated as a collision even when they render identically by design?
- What presentation is effective without modifying the value? Options include a warning indicator, highlighted characters, and a hover/focus details view showing code points, Unicode names, scripts, or an escaped representation.
- How should the experience remain accessible to keyboard and screen-reader users?
- How do we avoid noisy warnings for legitimate localized names and scripts?
- Can detection and presentation be implemented consistently across dashboard surfaces without adding significant client-side cost?

## Expected outcome

Document the recommended scope, detection rules, and UX. Validate the proposal against representative confusable, invisible, bidi, normalization, and legitimate international-text examples. If implementation is not part of this issue, create focused follow-up issues for the selected approach.

Start by reviewing the dashboard surfaces and externally supplied data categories named in the issue, then read Unicode Technical Standard #39 and the linked GitHub prior art. Validate proposed detection and presentation against the listed confusable, invisible, bidi, normalization, and legitimate international-text examples. Document the recommended scope, rules, accessible UX, and focused follow-up issues for implementation.

Written by the indexing model from the issue text.