Interactive HTML build report for JAR analysis

## Problem

The `jbundle analyze` command (see #4) currently proposes text-based output. A plain text breakdown of JAR contents is useful but limited — users cannot easily explore hierarchical data (packages → classes → methods), compare sizes visually, or drill into specific areas of concern.

## Inspiration

GraalVM's native-image generates a [Build Report](https://www.graalvm.org/latest/reference-manual/native-image/overview/build-report/) — a single self-contained HTML page with interactive visualizations:

- **Sunburst chart** showing hierarchical size breakdown (package → class → method level)
- **Image heap visualization** showing object types and their size contribution
- **Resource listing** with sizes and categories
- **Build metrics** (time per phase, memory usage, counts of types/methods)
- **SBOM (Software Bill of Materials)** for dependency tracking

Their [size optimization guide](https://www.graalvm.org/latest/reference-manual/native-image/guides/optimize-native-executable-size-using-build-report/) demonstrates how users can identify accidentally embedded resources, unnecessary dependencies, and bloated packages using these visualizations.

## Expected Outcome

`jbundle analyze --report` (or `jbundle analyze --format html`) should generate a self-contained HTML file with:

### Visualizations

- **Sunburst/treemap chart** of JAR contents: dependencies → packages → classes, sized by bytes
- **Runtime vs App split**: visual showing how much of the final binary is JVM runtime vs application code
- **Module dependency graph**: which jlink modules are included and why (from jdeps analysis)
- **Shrink impact**: before/after comparison showing what `--shrink` would remove

### Data Sections

- **Summary**: total size, class count, resource count, dependency count
- **Dependencies**: sorted by size, showing each library's contribution
- **Resources**: non-class files (XML, properties, native libs, fonts, etc.) with sizes
- **Namespaces**: Clojure AOT-compiled namespaces breakdown
- **Potential issues**: duplicate classes, suspiciously large resources, dev-only deps in production JAR
- **Build environment**: Java version, OS/arch, jbundle version, flags used

### Properties

- Single HTML file (no external dependencies) — can be shared, committed, or attached to CI artifacts
- Works offline (all JS/CSS inlined)
- Machine-readable companion output (JSON) for CI integration and trend monitoring

## Use Cases

- "Why is my binary 150MB?" → open report, immediately see which dependency dominates
- "Did adding library X bloat the build?" → compare two reports
- CI pipeline publishes report as artifact → team monitors size regressions over time
- Security review → SBOM shows all bundled dependencies and versions

Start with the `jbundle analyze` command described in #4 and trace how its current text output is produced. Define the report data needed for JAR contents, dependencies, resources, metrics, and shrink comparisons before choosing the HTML and JSON output paths. Done means `jbundle analyze --report` or `--format html` produces a self-contained offline report with the requested sections and visualizations.

Written by the indexing model from the issue text.