Template coverage does not register for components whose spec calls TestBed.overrideComponent

### Task Summary

Six component templates report **0% coverage** despite having substantial, passing specs, and adding tests to them does not change the number. Together they account for roughly 230 uncovered lines that no amount of test writing can reach.

| Template | Spec size | Reported |
|---|---|---|
| `hub-workflow-detail.component.html` | 442-line spec, 7 `detectChanges` | 0% |
| `user-project.component.html` | 262-line spec | 0% |
| `search.component.html` | 242-line spec | 0% |
| `workspace.component.html` | — | 0% |
| `hub-search-result.component.html` | — | 0% |
| `search-results.component.html` | — | 75.8% (partial) |

The common factor is `TestBed.overrideComponent`. Across the repo, templates whose spec calls it average **18%** coverage with 6 of 8 at zero; templates whose spec does not average **76.7%**, with only 2 of 73 at zero. Every one of these specs uses the additive `remove`/`add: { imports }` form to swap heavyweight child components for stubs — they do **not** override the template itself, so the real template genuinely renders and is genuinely exercised. It simply is not attributed.

Two counterexamples (`search-results`, `operator-property-edit-frame`) also call `overrideComponent` and do report coverage, so `overrideComponent` alone is not a sufficient explanation and the precise trigger is still unidentified.

### Why this matters

These files look like the largest remaining coverage gaps in the frontend, so they attract effort that cannot pay off. Two separate coverage sweeps ranked `hub-workflow-detail` (46 lines) and `user-project` (38 lines) near the top of the backlog before the pattern was spotted. Anyone working from the Codecov file list will keep rediscovering them.

### Suggested next steps

- Confirm the mechanism — most likely the component recompilation `overrideComponent` triggers produces a template with a different identity than the one the coverage remapper knows about.
- If it cannot be fixed, exclude these templates from the coverage denominator so the reported figure reflects what is actually testable, and note the reason.
- Either way, record it somewhere discoverable so the next person ranking targets does not spend the effort again.

### Task Type

- [ ] Refactor / Cleanup
- [x] DevOps / Deployment / CI
- [ ] Testing / QA
- [ ] Documentation
- [ ] Performance
- [ ] Other

Start by comparing the specs for hub-workflow-detail, user-project, search, workspace, hub-search-result, and search-results with the two counterexamples that also call TestBed.overrideComponent. Inspect the coverage attribution for these templates and determine why the additive override cases are missed. Done means coverage is correctly attributed, or the affected templates are explicitly excluded and the reason is recorded somewhere discoverable.

Written by the indexing model from the issue text.