test: enable child rendering in WorkspaceComponent spec

[Ma77Ball]

What changes were proposed in this PR?

Drops the <div #codeEditor> template stub from WorkspaceComponent's unit spec so the real workspace.component.html renders. Heavyweight children (workflow editor, panels, menu) are kept out of the test build by stripping
the component's imports/providers and adding CUSTOM_ELEMENTS_SCHEMA, leaving the <ng-template #codeEditor> outlet free to wire a live ViewContainerRef into CodeEditorService.vc. A new child rendering side effects describe block asserts that the editor-lifecycle wiring runs end-to-end (the published outlet is a real ViewContainerRef, proven by createEmbeddedView being a function on it).

Any related issues, documentation, or discussions?

Closes: #5015

How was this PR tested?

• yarn test --include="src/app/workspace/component/workspace.component.spec.ts" --watch=false: 20/20 pass (19 prior tests preserved, 1 new).
• yarn test --watch=false: full suite 445 passed, 2 skipped, 2 todo (no regressions).
• yarn format:fix: no rewrites.

Was this PR authored or co-authored using generative AI tooling?

Co-authored with Claude Opus 4.7 in compliance with ASF

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 43.05%. Comparing base (1ea368d) to head (ba46922).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #5037      +/-   ##
============================================
- Coverage     43.05%   43.05%   -0.01%     
  Complexity     2207     2207              
============================================
  Files          1045     1045              
  Lines         40216    40216              
  Branches       4243     4243              
============================================
- Hits          17315    17314       -1     
  Misses        21832    21832              
- Partials       1069     1070       +1     

Flag	Coverage Δ		*Carryforward flag
access-control-service	39.53% <ø> (ø)		Carriedforward from 1ea368d
agent-service	33.72% <ø> (ø)		Carriedforward from 1ea368d
amber	43.77% <ø> (ø)		Carriedforward from 1ea368d
computing-unit-managing-service	0.00% <ø> (ø)		Carriedforward from 1ea368d
config-service	0.00% <ø> (ø)		Carriedforward from 1ea368d
file-service	32.18% <ø> (ø)		Carriedforward from 1ea368d
frontend	33.93% <ø> (ø)
python	90.37% <ø> (ø)		Carriedforward from 1ea368d
workflow-compiling-service	47.72% <ø> (ø)		Carriedforward from 1ea368d

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Ma77Ball]

/request-review @mengw15

[mengw15]

Left some comments

[Ma77Ball]

@mengw15 I addressed the comments please let me know if it looks good now.

[mengw15]

Minor: this assertion relies on CodeEditorService.vc being undefined at the start of the test, which depends on TestBed rebuilding the injector between specs. That's the current behavior, but if the service ever becomes a longer-lived singleton (or test isolation config changes), this will start failing in ways that are hard to reproduce.

Consider making the starting state explicit so the test doesn't carry an implicit ordering dependency:

codeEditorService.vc = undefined as any;
await createFixture();
fixture.detectChanges();
expect(codeEditorService.vc).toBe(component.codeEditorViewRef);
expect(typeof codeEditorService.vc.createEmbeddedView).toBe("function");

Same outcome, no hidden DI assumption.