refactor(api): normalize application='ufs' to storage='ufs'

[HeyMeco]

Overview

This PR is one possible implementation of showing UFS images on the website as currently these images are only part of the dedicated applications section with no type showing. You could only make out that it is an UFS image by hovering over the link.

Another implementation could be just to show them in their respective category (like Desktop) with the correct UFS type

Screenshot

Before this PR:

[SuperKali]

This should be fixed API side not directly, i'm looking into it

[SuperKali]

Hi @HeyMeco, thanks a lot for spotting this and putting the work in — you correctly identified that UFS images were essentially invisible in the UI.

Looking at the root cause, the issue lived one layer upstream: the feed tags these images with application='ufs', which is semantically wrong (UFS is a storage-hardware dimension, not an application overlay like Kali or Home Assistant). That's why they ended up mis-classified under "Dedicated Applications" with no visual marker.

I pushed a small refactor on top of your branch (ce379a6): the fix now sits in the API normalizer (apps/api/src/services/normalizer.ts), where application='ufs' gets promoted to storage='ufs' and the application flag is cleared. This way UFS images fall into their natural category (minimal / desktop / server) and automatically get the cyan "UFS" chip in the Type column via the existing deriveChips mechanism — same pattern as QEMU, rootfs, QDL.

Net effect: the dedicated section, the duplicated table, and the three local filters in the downloads component all go away, and the whole thing collapses to 9 lines in the normalizer. Verified end-to-end against radxa-nio-12l (the only board currently shipping UFS images).

Thanks again — your PR is what surfaced this, and the data-model discussion wouldn't have happened otherwise.