Alternative compression algorithms (zstd, xz)

## Problem

The packed binary currently uses gzip (flate2) for the payload compression. While gzip is universally available, it does not offer the best compression ratio or decompression speed compared to modern alternatives. This directly affects two user-facing metrics:

1. **Binary size** — the final file users distribute
2. **First-run startup time** — time spent extracting the payload on initial execution

## Context

- The payload is a tar.gz containing `runtime/` (jlink output, ~30-50MB) and `app.jar`
- Decompression happens on every first run (or when cache is invalidated)
- Modern compression algorithms offer significantly better trade-offs:

| Algorithm | Compression Ratio | Decompression Speed | Availability |
|---|---|---|---|
| gzip | Baseline | Baseline | Universal |
| zstd | ~15-25% smaller | 2-3x faster | Widely available |
| xz/lzma | ~25-35% smaller | 2-5x slower | Common on Linux |

- For most users, **zstd** offers the best balance: smaller binaries AND faster first-run extraction
- **xz** is best for distribution size but penalizes the user on first run
- The stub script needs to know which decompression tool to invoke at extraction time

## Expected Outcome

A `--compress` flag that allows selecting the compression algorithm:

```bash
jbundle build --compress zstd # smaller + faster extraction
jbundle build --compress xz # smallest binary, slower extraction
jbundle build --compress gzip # current default, maximum compatibility
```

## Trade-offs to Consider

- **Compatibility**: gzip is available everywhere; zstd/xz require the tool to be installed on the target machine (or bundled decompression)
- **First-run experience**: xz saves download time but adds extraction time
- **CI caching**: smaller binaries mean faster artifact uploads/downloads

Start with the `jbundle build` entry point and trace the current gzip/flate2 packaging path through the stub script's extraction step. Define how `--compress` selects zstd, xz, or gzip, including the default and target-tool compatibility. Done means each documented command produces an extractable binary with the expected compression choice and preserves the current gzip behavior.

Written by the indexing model from the issue text.