filer: atomic conditional delete needs an exact entry version (IfNotModifiedAfter is second-resolution)

Describe the feature

Atomic conditional delete with an exact entry version — a follow-up to the discussion in #11338.

DeleteEntryRequest.IfNotModifiedAfter compares at second resolution (entry.Attr.Mtime.Unix() > ifNotModifiedAfter), and an entry that advanced within the same second still passes the guard. Clients that verify-then-delete (shell commands like fs.verify -pruneEntries and volume.fsck) can therefore delete a just-rewritten file when the replacement shares the original's mtime second and carries no MD5.

Proposed direction

Add an exact-version precondition to the delete path, e.g. one of:

• IfNotModifiedAfterNs (compare Mtime.UnixNano()), or
• an opaque entry version/revision that changes on every content update (including appends that keep mtime).

Clients would then pass the version observed during verification, making lookup→delete races impossible without extra RPCs.

Context

In #11338 the client-side mitigation is a chunk-set identity re-check plus IfNotModifiedAfter plus a post-delete confirmation, which closes the practical cases (same-second re-PUT, append) but leaves a sub-second lookup→delete window for MD5-less entries. A filer-side precondition closes it completely.