[PM-27134] feat: Add Register Passkey screen to TestHarness

[morganzellers-bw]

🎟️ Tracking

PM-27134

📔 Objective

Third PR in a 5-PR stack adding SDK-backed passkey test scenarios to TestHarness. Stacked on #2945.

• Adds the "Register Passkey (SDK)" scenario: a form for relying party ID, username, and display name that calls SDKPasskeyService.registerPasskey directly, showing the resulting credential ID and attestation object.
• Wires the new screen into the scenario picker and root navigation.
• Also drops the dead "Passkey Autofill" scenario stub (route: nil, already unused) and adds a missing accessibility identifier case for the TOTP scenario button, since this PR was already touching those files.

📸 Screenshots

---

Stack: #2945 → #2946 → #2947 → #2948

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Reviewed the new "Register Passkey" TestHarness screen (Action/Effect/State/Processor/View plus processor tests), its wiring into RootRoute/RootCoordinator/ScenarioPickerState/ScenarioPickerView, the MakeCredentialResult fixture, the localization key changes, and the doc-string edits across TestHarnessShared/Core/Autofill/Passkey. The screen follows the same unidirectional Store/Processor shape as the sibling TestHarness scenarios, passkeyService is injected from ServiceContainer through HasPasskeyService (typealias Services = HasErrorReportBuilder & HasPasskeyService), and the test file's setup/teardown ordering matches CardAutofillFormProcessorTests/CreateAccountFormProcessorTests. Every localization key the new view references resolves in TestHarnessShared/.../en.lproj/Localizable.strings (CredentialId, DisplayName, PasskeyRegisteredSuccessfully, RegisterPasskey, RegisterPasskeyFormDescriptionLong, RegistrationResult, RelyingPartyId added; Credentials, Username, XColonY already present), the orphaned PasskeyAutofill string is now removed with no remaining references, and Fixtures/MakeCredentialResult+Fixtures.swift lands only in TestHarnessSharedTests per the **/Fixtures/* include/exclude rules in project-bwth.yml. No security, correctness, or breaking-change findings — the retired ScenarioButton_Passkey identifier and the reassigned ScenarioButton_TOTPForm identifier have no consumers anywhere in the repo, and Lint/Test are green.

Code Review Details

• 🎨 : Editing a field mid-registration resets status to .idle, re-enabling the register button and allowing a concurrent duplicate registration (existing unresolved thread; no new comment posted)
  • TestHarnessShared/UI/Autofill/Passkey/RegisterPasskeyProcessor.swift:47-59

PR Metadata Assessment

• ❓ QUESTION: The Screenshots section is still a placeholder comment for a brand-new screen; please attach captures of the idle/success/failure states before merge.
• ❓ QUESTION: The description says the screen shows "the resulting credential ID and attestation object", but RegisterPasskeyView.statusSection renders only the credential ID.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.53%. Comparing base (c4f80a6) to head (2bd6942).

Additional details and impacted files

@@                               Coverage Diff                                @@
##           pm-40519-testharness-passkeys-sdk-foundation    #2946      +/-   ##
================================================================================
- Coverage                                         79.54%   79.53%   -0.01%     
================================================================================
  Files                                              1169     1169              
  Lines                                             75095    75095              
================================================================================
- Hits                                              59732    59730       -2     
- Misses                                            15363    15365       +2     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[claude]

🎨 SUGGESTED: Editing a field while a registration is in flight resets status to .idle, re-enabling the register button.

Details and fix

The text fields stay editable during registration (only the button is .disabled), so typing mid-flight sets status back to .idle. That hides the ProgressView and re-enables the Register button (RegisterPasskeyView.swift:83), which lets a second concurrent registerPasskey run and register a duplicate credential for the same RP — later ambiguous for assertPasskey(credentialId: nil, rpId:).

Guarding the reset keeps the in-progress state authoritative:

Suggested change

	override func receive(_ action: RegisterPasskeyAction) {
	switch action {
	case let .displayNameChanged(newValue):
	state.displayName = newValue
	state.status = .idle
	case let .rpIdChanged(newValue):
	state.rpId = newValue
	state.status = .idle
	case let .userNameChanged(newValue):
	state.userName = newValue
	state.status = .idle
	}
	}
	override func receive(_ action: RegisterPasskeyAction) {
	switch action {
	case let .displayNameChanged(newValue):
	state.displayName = newValue
	case let .rpIdChanged(newValue):
	state.rpId = newValue
	case let .userNameChanged(newValue):
	state.userName = newValue
	}
	if state.status != .inProgress {
	state.status = .idle
	}
	}