com_resources: play legacy video attachments instead of downloading them

[denphi]

The HTML5 player is only reachable when a child attachment's type alias is literally 'video'. Hubs that predate that type store plain video files under 'quicktime' or 'player', neither of which processPath() knows about, so they fall through to the download branch. On nanoHUB no 'video' type exists in the child-type category at all, which makes task=video unreachable: every mp4 gets a download link, even though both aliases sit in the $mediatypes list that labels them "View Presentation".

Route those two aliases to the player when the attachment is something the player can actually handle - one of the formats the manifest builder collects, living in the resource's own filespace. Externally hosted and absolute paths keep their existing behaviour, as does a caller explicitly asking for the file itself ($action 3), so the OAI-PMH miner still harvests direct file URLs.

primary_child() forces linkAction to 0 for a playable video: legacy logical types such as 'Podcast (video)' commonly carry a 'download' hint that would otherwise both relabel the button and beat the routing. The 'video' CSS class is what resources.js keys the inline embed off.

Also harden videoTask now that far more resources reach it:

• read and write the manifest through one path helper. The writer used filespace(), which derives the directory from the created date and a padded id; where that disagreed with the attachment's stored path the manifest was written somewhere the reader never looked, giving a permanent 404.
• name presentation.json explicitly instead of taking the first .json in the directory, so an unrelated sidecar cannot be loaded as the manifest and fatal the view.
• fall back to an in-memory manifest when the filespace is unwritable, rather than 404ing, and never cache an empty one.