Add TAR support and decide how nested archives are dealt with.

Nobody has claimed this yet.

Extend the ZIP archive support to TAR, and use this concrete extension step to design abstraction for handling nested archive situations.

`ArchiveHandler` already exists with generic methods and work with ZIP. TAR fits as new internal dispatch and a grounding format for the nesting decision.

When `iter_members` hits a member that's itself a supported archive (e.g., a .zip inside a .tar.gz), we probably want descent.

So we need a syntax for the output virtual path path (like `path/to/outer.tar.gz/inner.zip/file.txt`)

There are also risks of nested archives which could be mitigated by depth limit, cycle detection, handling members that fail to open (error or skipped warning?), probably others.

I would like to design the functionality around a "maximum trust" mode and set it up to descend into any arbitrary nested archive structure, and maybe start with just an opt-in flag that toggles nested archive descent.

And with this, set up a context object that can go along with the recursion which would be an extensible and independent way to handle nest problems. This way we can update security by configuring that object rather than refactoring nesting functionality.

Start by reading the existing ArchiveHandler and its iter_members implementation to understand the current ZIP dispatch. Define the TAR extension, nested-archive syntax, opt-in behavior, and safety decisions for depth, cycles, and failed members before implementation. No test files are named; done should include agreed behavior and coverage for the selected archive cases.

Written by the indexing model from the issue text.