Follow-up surfaced during #316 review.

Problem

Container listings served by handleGet (the JSON-LD / Turtle container representation) include per-entry dcterms:modified and stat:size fields for each child resource. The response's ETag is stats.etag, derived from the container directory's mtime/size.

But: modifying a child file's content typically does NOT bump the parent directory's mtime. So the listing body can change (different child mtime/size) while the container ETag stays the same.

Combined with Cache-Control: must-revalidate (added in #316), this is now a correctness issue: clients revalidate with If-None-Match, get 304, and keep a stale listing that doesn't reflect the child update.

Severity

Correctness. Clients may render outdated container listings until the directory's own mtime changes (e.g., a new file is added/removed).

Suggested fix

Compute a content-addressed ETag for container listings — e.g., hash of the sorted (name, size, mtime) tuples of the direct children, or hash of the serialized JSON-LD listing itself. The ETag must change whenever any field reflected in the listing body changes.

Scope note: This only affects container listings. Non-container resources use file mtime/size which correctly changes on write.