feat(dashboard): add public dataset card view

[xuang7]

What changes were proposed in this PR?

This PR adds a card view to the dataset listing, with a toggle to switch between the existing list view and the new card view for public dataset. Applied to the public dataset listing (/dashboard/hub/dataset/result).

Changes:

• Added DatasetCardItemComponent (frontend/.../user/dataset-card-item/, renders a dataset card with cover image, title, owner avatar + name, last-updated time, size, view count, and a like button. View mode persists per-user via localStorage.
• Decoupled SearchResultsComponent from any specific card component. It now accepts a cardTemplate: TemplateRef input, allowing each consumer to provide its own card via projection. The
  card branch is gated on viewMode === 'card' && cardTemplate.
• Extracted formatCount ("1.5k" style) and formatRelativeTime ("5 minutes ago" style) into frontend/src/app/common/util/format.util.ts. These mirror logic that already exists inline in the components (list-item, dataset-detail, hub-workflow-detail, user-computing-unit-list-item); the new card consumes the shared util.
• Added HubService.toggleLike helper, encapsulating the like/unlike + refresh-count flow.
• Projected DATASET.COVER_IMAGE through UnifiedResourceSchema and DatasetSearchQueryBuilder so search responses include the cover path needed by the card.

Any related issues, documentation, discussions?

Discussion #5130
Related to #4216 (workflow card view; same framework can later be applied).

Follow-up TODOs:

• 1. Enable card view on the user's personal dataset listing (/dashboard/user/dataset).
• 2. Fix cover image loading for private datasets ( requests can't carry the JWT header).
• 3. Replace the inline copies of formatCount and formatRelativeTime with the shared utility functions.

How was this PR tested?

Added test cases and manually tested.

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

Generated-by: Claude Opus 4.7

[codecov-commenter]

Codecov Report

❌ Patch coverage is 49.74359% with 98 lines in your changes missing coverage. Please review.
✅ Project coverage is 48.35%. Comparing base (f89c07c) to head (8f3282f).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
...dataset-card-item/dataset-card-item.component.html	54.83%	28 Missing ⚠️
frontend/src/app/common/util/format.util.ts	8.00%	23 Missing ⚠️
.../user/search-results/search-results.component.html	26.66%	21 Missing and 1 partial ⚠️
...r/dataset-card-item/dataset-card-item.component.ts	70.31%	13 Missing and 6 partials ⚠️
frontend/src/app/hub/service/hub.service.ts	0.00%	6 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##               main    #5215    +/-   ##
==========================================
  Coverage     48.34%   48.35%            
+ Complexity     2345     2344     -1     
==========================================
  Files          1042     1045     +3     
  Lines         39974    40153   +179     
  Branches       4251     4282    +31     
==========================================
+ Hits          19327    19414    +87     
- Misses        19505    19586    +81     
- Partials       1142     1153    +11     

Flag	Coverage Δ		*Carryforward flag
access-control-service	39.53% <ø> (ø)		Carriedforward from f2f72b4
agent-service	33.76% <ø> (ø)		Carriedforward from f2f72b4
amber	51.11% <100.00%> (-0.01%)	⬇️
computing-unit-managing-service	0.00% <ø> (ø)		Carriedforward from f2f72b4
config-service	0.00% <ø> (ø)		Carriedforward from f2f72b4
file-service	32.18% <ø> (ø)		Carriedforward from f2f72b4
frontend	40.12% <48.14%> (+0.09%)	⬆️
python	90.51% <ø> (ø)		Carriedforward from f2f72b4
workflow-compiling-service	56.81% <ø> (ø)		Carriedforward from f2f72b4

*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:

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

[Yicong-Huang]

I find myself not liking the cover image for a dataset. in fact in real usage, it's unlikely for a user to spend time to find a cover image for a dataset: it will likely become the default image instead.

Thus I suggest remove the image, or at least make it optional.

[Yicong-Huang]

@xuang7 could you please also add more tests to make coverage happy? thanks!

[xuang7]

I find myself not liking the cover image for a dataset. in fact in real usage, it's unlikely for a user to spend time to find a cover image for a dataset: it will likely become the default image instead.

Thus I suggest remove the image, or at least make it optional.

Thanks for the suggestion! I agree that many datasets may not have a custom cover image in real usage, and it is possible that most of them will fall back to the default image, similar to what we currently have on the Hub featured workflow.

I think the image area helps make the card view more visually distinguishable, since we do not have many metadata fields yet, such as tags, dataset format, or subtitle/summary information. Without an image, the cards may look a bit plain and information-heavy.

That said, we could also make the image optional, use a more compact layout where the cover image takes up a smaller portion of the card, like the attached example, or remove it entirely. I'm open to adjusting the design.

I will add more tests to improve the coverage. I'm still considering whether to split this into two smaller PRs since the current PR is getting a bit large. Thanks! @Yicong-Huang

[Yicong-Huang]

Thanks! I actually would prefer a style like

a few reasons:

1. it uses labels to quickly give out important metadata like csv biomedical and classification.
2. columns (like schema) is good, better have name if possible, show first two or three columns is enough.
3. it has more space for dataset name, which is IMO most important info.
4. it also shows number of rows and size of the dataset.
5. I think it is hard to ask user to upload an image to visually distinguish a dataset. we can use icons. two options: 1. use a preset of colors/emojis for user to choose for icon, similar to iPhone contact icons. 2. call an AI api to generate one icon on the fly. cover image is too heavy, icons are good alternative.

[Yicong-Huang]

@xuang7 I think you need to create an issue. after a discussion, when we have consensus to do something or go with a direction, please create an issue as "To do task" to track it. The discussion could contain back and forth conversations. the issue serves as a "decision" or "summary".

on this particular case, the discussion in #5130 only covers list vs cards. I think (based on my reading) the card view got the most votes. but the details of the card was never discussed. it might be fine, but that might be the reason we are doing discussion here in the PR about what info to put inside the card (i.e., image or not).

[xuang7]

@xuang7 I think you need to create an issue. after a discussion, when we have consensus to do something or go with a direction, please create an issue as "To do task" to track it. The discussion could contain back and forth conversations. the issue serves as a "decision" or "summary".

on this particular case, the discussion in #5130 only covers list vs cards. I think (based on my reading) the card view got the most votes. but the details of the card was never discussed. it might be fine, but that might be the reason we are doing discussion here in the PR about what info to put inside the card (i.e., image or not).

Sounds good. I will do another round of voting to reach a final decision, and create a separate issue related to this PR to summarize and track the card view design details. Thanks for the suggestions!

[Yicong-Huang]

Sounds good. I will do another round of voting to reach a final decision, and create a separate issue related to this PR to summarize and track the card view design details. Thanks for the suggestions!

we don't need a vote (too official), but good to discuss design before start. just want to avoid waste of implementing PR and reviews.

[xuang7]

Sounds good. I will do another round of voting to reach a final decision, and create a separate issue related to this PR to summarize and track the card view design details. Thanks for the suggestions!

we don't need a vote (too official), but good to discuss design before start. just want to avoid waste of implementing PR and reviews.

Yes, that makes sense. By "voting," I meant that I will add a proposed design solution to the discussion/issue and see if there are more comments or suggestions about the design.

[chenlica]

I agree that no official vote is needed.