The dashboard's volume usage metric reports the storage layer's allocated blocks (ZFS usedbydataset), not the logical size of files inside the container. When files are deleted or rewritten, the freed blocks are only returned when they are discarded back to the storage layer, and because the volume allocates in 16 KB blocks while the container's filesystem frees in 4 KB blocks, partially freed blocks can never be returned, so the metric settles permanently above what df/du reports. Your df and du agreeing at ~8 MB confirms the data inside your container is fine and there is nothing to fix. Billing is based on this same metric (averaged per minute at $0.15/GB-month), but the dollar impact of the gap is typically small.

Thank you for the explanation! Is there a safe way to reclaim the approximately 300 MB of allocated space that is no longer being used by my files? If this requires recreating or migrating the volume, how can I do it without losing my SQLite database or backups? Could this allocated space eventually cause my volume to reach its capacity limit, and is there a way to prevent the discrepancy from growing?

There is no way to reclaim those allocated blocks - the 16 KB block floor is permanent, fstrim is not permitted inside containers, and we do not offer a volume-rebuild workaround for bringing the number down. The gap does not grow without bound because continuous discard handles ongoing frees, so it settles rather than creeping toward your 500 MB cap on its own, and at ~460 MB of excess the billing impact is roughly $0.07/month.