feat(frontend, amber): offer the owners of what each page actually shows

[tanishqgandhi1908]

What changes were proposed in this PR?

Every page has an Owner dropdown, and it should list the people who own the things on that page. On the unified search page and on the hub, it didn't.

Page	What the page shows	What the dropdown listed
Your Work → Workflows / Datasets / Models	what you own or were granted	owners of those	✅
Search — Workflow tab	your + public workflows	owners of your workflows	⚠️ missing public owners
Search — Dataset tab	your + public datasets	owners of your workflows	❌ wrong kind
Search — Model tab	your + public models	owners of your workflows	❌ wrong kind
Search — All tab	your + public, all kinds	owners of your workflows	❌ wrong kind
Hub → Workflows / Datasets / Models	public resources	owners of your private resources	❌ wrong people

Two causes:

1. The search page never told the filter which tab was active. search.component.html rendered <texera-filters> with no [entityType], so the bar kept its EntityType.Workflow default on every tab.
2. Nothing could ask "who owns the published ones?" All three *-owners endpoints filter on the caller's own access rows, which is right for Your Work and wrong for the hub.

Reproduced before the fix, with texera owning 2 workflows / 3 datasets / 3 models, bob owning 1 workflow and 1 private dataset, and alice owning 1 public model:

	Before	After
Search → Model tab, dropdown	texera, bob@test.com — bob owns no model	texera, alice@test.com — the public model's owner
…ticking the wrong name	tab goes empty	no wrong name is offered
Hub → Datasets as bob, dropdown	bob@test.com, texera — bob has nothing public	texera — exactly the owner on screen
…ticking bob	hub goes empty	bob is no longer offered

Backend — one endpoint, not three. HubResource.getCount already runs where(isPublicColumn.eq(true)) over a per-kind registry covering all three kinds, so GET /hub/owners?entityType= is its sibling. BaseEntityTable gains a joinWithOwner, implemented once in VersionedResourceTables for dataset and model, and once for workflow. Deliberately not
joinWithAccessAndOwner(None), which left-joins the access table and fans out a row per grant. The three existing *-owners endpoints are untouched.

Frontend. FiltersComponent gains an ownerScope input, and entityType accepts null for a page listing every kind. ResourceRegistryService.ownersFor(type, scope) resolves the rest:

FiltersComponent now implements OnChanges, so switching tabs refetches; the reload runs through a switchMap, or a fast run of tab clicks would let a stale response land last and repopulate the facet with the previous kind's owners.

This is a feat rather than a fix: it adds an endpoint and a new input, and it touches model and registry code that release/v1.2 does not have, so it should not be backported.

Deliberately unchanged: signed-out visitors still get no Owner dropdown. The list is email addresses, and serving those to anonymous callers on a public hub is email harvesting — so the new endpoint is @RolesAllowed like its siblings.

Behaviour worth calling out in review: switching tabs with an owner chip selected that the new kind has no owner for drops the chip and shows the existing "Invalid owner name" toast. Silently keeping it is what produced the mystery-empty page this PR is fixing.

Unified search, Model tab

In both shots the page lists one model, empty-model, owned by texera. Look at the Owner dropdown
open at the top right.

Before — it offers texera and bob@test.com. Those are the workflow owners: bob owns no
model, and ticking him empties the tab.

After — it offers texera and alice@test.com. Those are the model owners: bob is gone, and
alice appears because she owns a public model, which this page lists.

Hub → Datasets, signed in as bob

In both shots the hub lists one dataset, public-weather, which is public and owned by texera.

Before — the dropdown offers bob@test.com and texera. bob is offered because he owns a
private dataset of his own, which cannot appear on this page; ticking him empties the hub.

After — the dropdown offers texera alone: exactly the owner of what is on screen.

Any related issues, documentation, discussions?

Closes #8385.

How was this PR tested?

Backend — 6 new cases in HubResourceSpec (82 passed):

• owners of published workflows and no one else
• an owner named once however many public entities they have
• a grant is ignored — the bug itself: a user holding a grant but publishing nothing is not offered
• each kind kept to its own table, with a different owner per kind so a mix-up cannot pass
• owners of private entities left out
• nobody named for a public workflow with no owner row

Frontend — 277 passed across the eight affected specs. New cases cover: per-scope routing
(asserting the other endpoint is not called), the union across kinds, a person owning several kinds
named once, a kind whose request fails contributing nothing rather than blanking the facet, reload on
kind change, exactly one load on first render, and both the dropped and the surviving owner chip.

sbt 'testOnly *HubResourceSpec *EntityTablesSpec'
cd frontend && npx ng test --include src/app/dashboard/component/user/filters/filters.component.spec.ts \
  --include src/app/dashboard/service/user/resource-registry/resource-registry.service.spec.ts \
  --include src/app/dashboard/component/user/search/search.component.spec.ts \
  --include src/app/hub/component/hub-search-result/hub-search-result.component.spec.ts

End-to-end against a local stack: the table above is the actual before/after, and
GET /hub/owners returns ["texera"] for datasets where the old access-scoped endpoint returned
["bob@test.com","texera"].

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

Generated-by: Claude Code (Opus 5)

[github-actions]

Backport auto-label report

This fix: PR was checked against each actively-supported release branch. release/* labels drive the post-merge backport, so add or remove one to change where this fix lands.

Release branch	Analysis
✅ release/v1.3	Change detected on this branch — label added; this fix is queued to backport here. Requested review from @mengw15.
✅ release/v1.2	Change detected on this branch — label added; this fix is queued to backport here. Requested review from @xuang7.

Auto-label run.

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• Contributors with relevant context: @aglinxinyuan, @yangzhang75, @mengw15
  You can notify them by mentioning @aglinxinyuan, @yangzhang75, @mengw15 in a comment.

[github-actions]

⚠️ Benchmark changes need a look

🟢 0 better · 🔴 10 worse · ⚪ 5 noise (<±5%) · 0 without baseline

Compared against main 905c17d benchmarked on this same runner, so the delta is largely free of cross-runner hardware noise. The "7d avg" column still reflects the gh-pages dashboard. Treat <±5% as noise unless repeated.

Dashboard · Run

	config	throughput	MB/s	latency	max Δ latest / 7d
🔴	bs=10 sw=10 sl=64	567	0.346	18,211/21,418/21,418 us	🔴 +27.0% / 🔴 +40.8%
🔴	bs=100 sw=10 sl=64	1,192	0.728	82,377/109,912/109,912 us	🔴 +15.8% / 🟢 +22.2%
⚪	bs=1000 sw=10 sl=64	1,476	0.901	680,025/740,716/740,716 us	⚪ within ±5% / 🟢 +46.7%

Baseline details

Latest main 905c17d from same runner

config	metric	PR	latest main	7d avg	Δ latest	Δ 7d
bs=10 sw=10 sl=64	throughput	567 tuples/sec	684 tuples/sec	755.36 tuples/sec	-17.1%	-24.9%
bs=10 sw=10 sl=64	MB/s	0.346 MB/s	0.417 MB/s	0.461 MB/s	-17.0%	-25.0%
bs=10 sw=10 sl=64	p50	18,211 us	14,341 us	12,938 us	+27.0%	+40.8%
bs=10 sw=10 sl=64	p95	21,418 us	17,970 us	15,980 us	+19.2%	+34.0%
bs=10 sw=10 sl=64	p99	21,418 us	17,970 us	19,233 us	+19.2%	+11.4%
bs=100 sw=10 sl=64	throughput	1,192 tuples/sec	1,354 tuples/sec	976.3 tuples/sec	-12.0%	+22.1%
bs=100 sw=10 sl=64	MB/s	0.728 MB/s	0.827 MB/s	0.596 MB/s	-12.0%	+22.2%
bs=100 sw=10 sl=64	p50	82,377 us	71,394 us	102,340 us	+15.4%	-19.5%
bs=100 sw=10 sl=64	p95	109,912 us	94,935 us	109,262 us	+15.8%	+0.6%
bs=100 sw=10 sl=64	p99	109,912 us	94,935 us	118,827 us	+15.8%	-7.5%
bs=1000 sw=10 sl=64	throughput	1,476 tuples/sec	1,489 tuples/sec	1,006 tuples/sec	-0.9%	+46.7%
bs=1000 sw=10 sl=64	MB/s	0.901 MB/s	0.909 MB/s	0.614 MB/s	-0.9%	+46.7%
bs=1000 sw=10 sl=64	p50	680,025 us	665,988 us	999,855 us	+2.1%	-32.0%
bs=1000 sw=10 sl=64	p95	740,716 us	753,622 us	1,042,833 us	-1.7%	-29.0%
bs=1000 sw=10 sl=64	p99	740,716 us	753,622 us	1,070,722 us	-1.7%	-30.8%

Raw CSV

config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,352.43,200,128000,567,0.346,18210.62,21418.03,21418.03
1,100,10,64,20,1677.81,2000,1280000,1192,0.728,82377.39,109912.22,109912.22
2,1000,10,64,20,13551.35,20000,12800000,1476,0.901,680024.61,740715.69,740715.69

[codecov-commenter]

Codecov Report

❌ Patch coverage is 98.57143% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 94.05%. Comparing base (cd4fd5a) to head (146a350).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...hboard/component/user/filters/filters.component.ts	96.29%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8386      +/-   ##
============================================
+ Coverage     94.03%   94.05%   +0.01%     
- Complexity     4771     4775       +4     
============================================
  Files          1196     1196              
  Lines         48757    48826      +69     
  Branches       5916     5928      +12     
============================================
+ Hits          45850    45921      +71     
+ Misses         1458     1457       -1     
+ Partials       1449     1448       -1     

Flag	Coverage Δ		*Carryforward flag
access-control-service	81.00% <ø> (ø)		Carriedforward from cd4fd5a
agent-service	99.32% <ø> (ø)		Carriedforward from cd4fd5a
amber	89.92% <100.00%> (+0.02%)	⬆️
computing-unit-managing-service	73.67% <ø> (ø)		Carriedforward from cd4fd5a
config-service	87.12% <ø> (ø)		Carriedforward from cd4fd5a
file-service	87.91% <ø> (ø)		Carriedforward from cd4fd5a
frontend	96.81% <98.27%> (+<0.01%)	⬆️
notebook-migration-service	79.31% <ø> (ø)		Carriedforward from cd4fd5a
pyamber	98.47% <ø> (ø)		Carriedforward from cd4fd5a
workflow-compiling-service	77.19% <ø> (ø)		Carriedforward from cd4fd5a

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

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

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.