Decouple auth.service from RegistrationRequestModalComponent

[Yicong-Huang]

Task Summary

Break the import chain auth.service → RegistrationRequestModalComponent so the modal's template stops being type-checked through every spec that uses anything in the auth-touching code path. This single source change unblocks 13 service specs that PR #4862 had to exclude.

Why

auth.service.ts directly imports RegistrationRequestModalComponent and passes the class to NzModalService.create({ nzContent: RegistrationRequestModalComponent }). The modal is @Component({ standalone: false }) and its template uses [ngModel] — under the new unit-test builder, the modal's template fails the strict NG8002 check.

Any spec that imports auth.service (directly or transitively) drags the modal's template through type-checking. Currently affecting:

• coeditor-presence.service.spec.ts
• execute-workflow.service.spec.ts
• user.service.spec.ts
• workflow-websocket.service.spec.ts
• workflow-result-export.service.spec.ts
• udf-debug.service.spec.ts
• user-config.service.spec.ts
• operator-menu.service.spec.ts
• workflow-console.service.spec.ts
• operator-reuse-cache-status.service.spec.ts
• workflow-result.service.spec.ts
• download.service.spec.ts
• preset.service.spec.ts

Two viable approaches

A. Convert RegistrationRequestModalComponent to standalone.

@Component({
  standalone: true,
  imports: [CommonModule, FormsModule, NzModalModule, NzInputModule, NzFormModule],
  ...
})

Pros: smallest delta, addresses the symptom directly.
Cons: doesn't decouple auth from the modal, leaves the architectural smell.

B. Lazy-load the modal via a token

Provide the modal component class through a DI token that auth.service injects, instead of importing it directly. The DI binding lives in the module that wires up auth + UI.

Pros: cleaner separation; auth.service no longer imports a UI component.
Cons: more invasive, touches multiple files.

Recommendation: A as a quick unblock; revisit B as part of a broader auth/UI cleanup if desired.

Definition of done

• The 13 specs above compile under the unit-test builder without pulling the modal's template through their dep graph.
• Exclusion entries removed from tsconfig.spec.json and angular.json.
• workflow-result.service.spec.ts already has its done-callback rewrite landed in feat(frontend): migrate test runner Karma → Vitest #4862 — it should run cleanly once the auth chain is unblocked.

[Yicong-Huang]

Resolved by #4873. The standalone-component migration made RegistrationRequestModalComponent a standalone: true component with its own imports: [FormsModule, NzInputModule, ...], so the modal's template no longer depends on AppModule's directive scope. auth.service still imports the class directly (the ergonomic path), but the spec-compile failure that originally motivated this issue is gone — service specs that transitively reach auth.service no longer fail NG8002 on the modal's template. (The cleaner Approach B from this issue's body — token-based decoupling — is still architecturally nicer but not blocking anything; can be picked up later if useful.)