feat(dashpay): show the requested variant next to a normalized contested label

[QuantumExplorer]

Issue being fixed or feature implemented

Testnet QA: requesting "quiet" shows up under My Names → In network vote as "qu1et" — DPNS normalization folds look-alike characters (i/l → 1, o → 0), and the row only displayed the network's normalized label, not what the user typed.

What was done

contestedRow now shows both forms when they differ: the requested variant ("quiet") as the title — recovered by running each submission bookmark through dpnsNormalizeLabel and matching it to the SDK cache's normalized label — with the normalized form ("qu1et") beside it in the tertiary tone. The variant is what the user asked for; the normalized form is what the network actually registers. Rows whose typed form already equals the normalized form are unchanged.

How Has This Been Tested?

Clean dashpay arm64 simulator build; installed on the testnet QA simulator carrying a live "quiet"→"qu1et" contest among four in-flight requests — screenshot verification in the same QA session. (Unit-test target pre-existing broken.)

Breaking Changes

None.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes
  • Contested-name entries now show the exact label variant you requested when it differs from the network-normalized version.
  • Improved display accuracy for pending username marketplace requests.

[coderabbitai]

📝 Walkthrough

Walkthrough

The marketplace now recovers user-entered contested-label variants from pending requests. Contested-name rows show the requested variant and the normalized network label when they differ.

Changes

Username variant display

Layer / File(s)	Summary
Recover and render requested variants DashWallet/Sources/UI/Explore Dash/UsernameMarketplaceScreen.swift	The view model matches pending requests to normalized labels. Contested rows show the requested variant with the normalized label when the values differ.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• dashpay/dashwallet-ios#933: Extends related username-display changes with requested contested-label variants.
• dashpay/dashwallet-ios#946: Extends the UsernameMarketplaceScreen.swift implementation with contested-name variant display.
• dashpay/dashwallet-ios#955: Extends contested-name row UI to show the original requested variant.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: displaying the requested variant beside a normalized contested label.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/contested-variant-display

---

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

DashWallet/Sources/UI/Explore Dash/UsernameMarketplaceScreen.swift (1)

563-563: 🚀 Performance & Scalability | 🔵 Trivial | ⚡ Quick win

Cache requested variants before rendering rows.

Line 563 performs a synchronous SDK-backed scan while SwiftUI builds each contested row. Each state update can repeat O(contested rows × pending labels) work on the main actor. Build a normalized-label-to-requested-label lookup when the ViewModel loads the data, then use a dictionary lookup in contestedRow.

As per coding guidelines, keep SwiftUI views lightweight.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@DashWallet/Sources/UI/Explore` Dash/UsernameMarketplaceScreen.swift at line
563, Update the ViewModel’s data-loading flow to precompute a
normalized-label-to-requested-label dictionary for all contested rows, avoiding
repeated SDK-backed scans during rendering. In contestedRow, replace
requestedVariant(forNormalized:) with a direct lookup in the cached dictionary
while preserving the existing row behavior when no requested label exists.

Source: Coding guidelines

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@DashWallet/Sources/UI/Explore` Dash/UsernameMarketplaceScreen.swift:
- Line 563: Update the ViewModel’s data-loading flow to precompute a
normalized-label-to-requested-label dictionary for all contested rows, avoiding
repeated SDK-backed scans during rendering. In contestedRow, replace
requestedVariant(forNormalized:) with a direct lookup in the cached dictionary
while preserving the existing row behavior when no requested label exists.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 6354b9a2-491c-4531-a642-086bf2cf1ecb

📥 Commits

Reviewing files that changed from the base of the PR and between 62f9da7 and 6c1e66b.

📒 Files selected for processing (1)

• DashWallet/Sources/UI/Explore Dash/UsernameMarketplaceScreen.swift