Keep a feed's items and files to the people who subscribe to it (#129)

Routes that take a feed or an enclosure id did not check who was asking. Anyone signed in could
read any feed's items through GET /api/feeds/{id}/entries, a paid feed's included, with the
addresses of its files, which can carry the subscriber's key: the Directory leaves such feeds
out for that reason, and this route handed them back to whoever guessed the id, a slug of the
title. In production it answered 25 items of a feed the asking account does not subscribe to.
/media/{id} served any downloaded file by its sequential id, POST /api/enclosures/{id}/download
and /api/feeds/{id}/download-latest queued any feed's downloads, and DELETE
/api/enclosures/{id}?force=true deleted any file.

Each now answers 404, "you do not subscribe to that feed", unless the person subscribes to it.
A feed inside an OPML has a subscription row of its own for everyone subscribed to the OPML, so
that holds for those feeds too. Found while adding the Directory's feed page (#128), which has
its own route that answers only for listed feeds and carries no files.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture.md

@@ -110,7 +110,8 @@ so a long download had to be able to notice the signal itself.
 ## HTTP API
 
 Everything below `/api` needs a signed-in user; the browser gets a redirect to `/login`, anything
-else a `401`.
+else a `401`. A feed's items and files (its entries, `download-latest`, `/api/enclosures/{id}` and
+`/media/{id}`) answer only someone who subscribes to the feed; anyone else gets a `404`.
 
 | Route | |
 |---|---|