Consider protecting files other sites' custom fonts use when removing core fonts #2026

On multisite the fonts folder is shared, but each site keeps its own custom font records. #2012 stops a custom font delete or edit from removing a file another site's custom font still uses. Core font removal doesn't have that check yet, so a custom record on another site that points at a core-named file under its own font key isn't seen. This is worth considering once #2012 lands.

Where it matters

• Model_Font_Downloader::delete_downloaded_font() checks use by font key (each site's default font, locale and PDF fonts), then removes the family's files whatever their contents. If another site's custom font uses Garuda.ttf with different bytes, the delete removes that site's font. The next render downloads core Garuda under that name, so the site silently gets the wrong font.
• Model_Font_Downloader::prune() resolves every site's font keys through the cron site's font list, so a custom key only another site has resolves to no files. Impact is smaller here: it only removes unmodified core files, and On_Demand_Font_File_Finder downloads a missing core-named file at render. PDFs only degrade when downloads are off or failing, and then they fall back to Arimo.

Possible approach

• Add a version of Model_Custom_Fonts::get_files_used_by_other_sites() that can include the current site, because prune() runs on the cron site and needs every site's records.
• Pass it through Model_Font_Sources to the downloader, as is_record_file() already does.
• In delete_downloaded_font(), skip those files as custom deletes do, and merge them into what prune() keeps.

Out of scope

A custom font delete doesn't need to check whether other sites use the same file as a core font. That would walk every form on every site for each delete, to protect a file that downloads again on its own.

Both code paths are new in 6.19, so this wouldn't need a 6.18.x backport.