feat(album): show total album size on the album header

[Thomas05000005]

Summary

Shows the total size of an album right next to the existing track count and runtime on the album screen header. The size is computed by summing the Size field of each track's first MediaSourceInfo and is rendered with an adaptive B / KB / MB / GB formatter. The row is hidden whenever the server does not report sizes for any track in the album.

Closes #1146 (scoped to the first bullet only - the other three were already separately addressed or duplicated, per the maintainer's reply on the issue).

Implementation

Three small files:

• lib/components/format_bytes.dart (new) - top-level formatBytes(int) helper that picks B, KB, MB or GB based on the magnitude. Modeled on the existing print_duration.dart (also a top-level helper in the same folder, no class).
• lib/components/AlbumScreen/item_info.dart - reads each track's mediaSources?.first?.size, sums them with fold, and adds an IconAndText(iconData: Icons.sd_storage, ...) between the track-count/duration row and the release-date row when the total is greater than zero.
• lib/services/jellyfin_api.dart - adds MediaSources to the defaultFields constant. Without this, the Items API does not include mediaSources in the response, so t.mediaSources?.first?.size is always null and the size row never appears. The MediaSources field is documented as a valid Fields value directly in the same file's getItems parameter docstring.

Notes

• Conflict with fix(api): request SortName field so fast scroll matches the sorted list #1619 expected: that PR also amends defaultFields (it adds SortName). If fix(api): request SortName field so fast scroll matches the sorted list #1619 lands first, this PR will need a trivial rebase to keep both fields. If reviewers prefer a single PR that adds both fields, I can fold them together - happy to follow whichever is easier on review.
• I deliberately did not add a FinampSettings toggle for this. The original report and the maintainer's response treat the size as plain metadata to display, in line with how track count and duration are already shown. A toggle could always be added in a follow-up if reviewers want one.
• The size is read from MediaSourceInfo.size (already on the existing BaseItemDto.mediaSources field). Computation happens once per ItemInfo.build, which already runs on each album-screen open - same cost as the existing runTimeTicksDuration summation a few lines above.
• If a track is missing both mediaSources and mediaSources.first.size, it contributes 0 to the sum. The row is hidden when the total is 0, so albums where no track has a size value reported render exactly as today.
• Binary units (1024-based) to match how disk usage is typically displayed on mobile OSes; happy to swap to decimal (1000) or to a localized formatter if you prefer.

Test plan

Tested on Windows desktop (flutter run -d windows) against a real Jellyfin server:

• Open an album whose tracks have a Size reported by the server: a row with the SD-storage icon shows the formatted total (verified, e.g. "32.9 MB" on a one-track album)
• MediaSources was confirmed required: without it on defaultFields the row never appeared even when the player itself shows the per-track size when playing
• Open a playlist: the size row works the same way (sums up across the playlist's tracks)
• Numbers stay readable on narrow window widths

Out of scope (per maintainer's reply on the issue)

• Persistent download button after an album is downloaded - already re-added on the downloads screen
• Offline favorites/playlists - duplicate of [Feature Request] Create playlist in offline mode and add tracks to pl when offline. #1065 and Support liking/unliking and adding/removing tracks when offline #933
• "Wrapped"-style highlights - handled by jellyfin-rewind

Code assistance

Used Claude (LLM) to follow the existing helpers' structure, to discover that the size lives on MediaSourceInfo rather than on BaseItemDto directly, and to find that MediaSources had to be added to defaultFields for the Items API to actually include the data we read.