Support 7z extraction, and fix .xz extraction which would have crashed at runtime

Commons Compress declares its LZMA/LZMA2 support against org.tukaani:xz as an *optional* dependency, so nothing pulled it in transitively and nothing failed at build time. The app nevertheless advertised .xz as extractable, so the first user to open one would have got NoClassDefFoundError: org/tukaani/xz/FilterOptions. XZCompressorInputStream references org/tukaani/xz/XZInputStream directly. The library is now declared, and a round-trip test covers the path that was silently missing.

That same library is what 7z needs, and Commons Compress already ships a pure-Java 7z reader, so 7z extraction costs no native code and no further dependency. The docs had assumed the format was off limits and said so in three places, including the customer-facing store copy.

7z is the only format here that cannot arrive through a stream: its header sits at the end of the file, so the reader has to seek. That is now a capability the backend advertises, StorageSource.openSeekable: the all-files backend answers with a real FileChannel, the SAF fallback with null, so folder mode reports needs-a-seekable-file instead of failing obscurely. Entry names go through the same ArchivePath.safeRelativePath zip-slip guard. 7z creation stays deferred.

app/build.gradle.kts

@@ -181,6 +181,9 @@ dependencies {
 
     // ZIP/TAR/GZ archive support. Pure Java — no native code, no NDK.
     implementation(libs.commons.compress)
+    // Commons Compress's JVM-only dependencies for LZMA/LZMA2: `.xz` and 7z. Optional
+    // upstream, so it has to be declared here or those formats fail at runtime.
+    implementation(libs.xz)
 
     debugImplementation(libs.androidx.compose.ui.tooling)