fix(zip): read an entry name with a leading slash as relative

[andiwand]

🤖 Generated with Claude Code

A reported .odt did not open: its zip carries the odf manifest's root entry
(manifest:full-path="/") as a real zip entry named /, holding a second copy
of content.xml's bytes. zip::Archive::Entry::path() built a RelPath from
that name and threw not a relative path, so the file failed before any
decoding began. LibreOffice refuses the file too — removing that one entry is
what makes soffice --convert-to load it.

APPNOTE.TXT 4.4.17.1 says an entry name is always relative to the archive root,
so a leading slash is malformed and the tolerant read is to drop it. The name
now goes through Path(...).make_relative(), and a name that is nothing but
the root normalises to the empty path, which addresses no entry — ZipArchive
skips it.

Nothing else in the corpus moves: a well-formed name is unchanged by
make_relative(), and any input that did carry an absolute name would have
thrown before, so none is in there.

The rendered text of the new fixture matches LibreOffice's .txt export of the
same file with the stray entry removed, character for character.

Test data

• input odt/zip-root+entry-1.odt, with the original name recorded in
  index.csv and flagged confidential — it is a filled-in police form with
  personal data
• reference output for it, on top of feat(html): an editing mode for a sheet, and the locks it refuses on #861's, which main already pins