feat(dashpay): persistent username row in the home header nav bar (SB-11)

[romchornyi]

Issue being fixed or feature implemented

SB-11. The DashPay profile entry point lived only on the UIKit navigation bar's avatar, which #813 made scroll-gated: hidden at the top of the feed, revealed past kTopBarShowThreshold. On a feed shorter than the viewport that threshold can never be crossed, so the avatar — and with it the only way into "my profile" — was unreachable.

What was done?

• Moved the bar into the balance header, which is always on screen at the top of Home: DashUIKit.NavigationBar with the username row leading, the Dash wordmark central, and the notifications bell trailing.
• New HomeUsernameRow reuses ContactAvatarView and the existing profileAction() target, so there is one source of truth for opening the profile rather than a second tap path.
• HomeView measures scrollable-content height against the ScrollView's own viewport (HomeContentHeightKey / HomeViewportHeightKey) and keeps the old UIKit bar shown when the feed is too short to scroll the threshold, so the existing reveal gesture cannot strand it either. A zero viewport height means the first layout pass has not reported yet — it waits for a real measurement instead of flashing the bar on a feed that is long enough.
• The bell's unread state and the username/avatar come from the same app-owned identity and contacts snapshots the UIKit bar uses, refreshed on DWDashPayRegistrationStatusUpdated and the contacts snapshot notification, so a new username or an incoming request lands without leaving Home.
• Added SwiftUI previews for HomeUsernameRow and ContactAvatarView (placeholder initials, sizes, empty-title fallback).

All of it is #if DASHPAY; the non-DashPay build compiles the bar out.

How Has This Been Tested?

Not built. The SwiftDashSDK package in ../platform is on feat/platform-wallet-dashconnect-ffi and fails with value of type 'EventHandlerCallbacks' has no member 'release_fn', so the app target was never reached.

Static checks done: DashUIKit.NavigationBar, Color.dash.whiteText / .white, the icon_bell / icon_bell_active / logo assets, notificationAction(), DWDashPayRegistrationStatusUpdated and homeViewDidChangeTopBarVisibility all resolve, and HomeUsernameRow.swift is registered in both targets in the project file.

Before merge this needs a dashpay arm64-sim build plus a device pass on: no identity (row hidden), registered username with and without an avatar, a feed short enough to skip the reveal threshold, and an incoming contact request lighting the bell live.

Breaking Changes

None. HomeViewDelegate gains homeViewShowNotifications(), implemented by the single conformer (HomeViewController) inside #if DASHPAY.

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

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5d63811e-04ce-4947-a0fe-f745be04b8d4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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