Build the SBOM incrementally through the lifecycle

SBOMs should be built the way artifacts are: step by step, each stage transforming the output of the previous one. Today the BOM is derived in a single pass from the resolved dependency graph, so anything the POM cannot express is invisible: shaded content, native libraries, bundled front-end assets, annotation processor output.

Sketch of the model, as small goals bound to lifecycle phases:

1. `compile`: record pedigree of the compiled output, such as the source Package URL (or SWHID) and the annotation processors that ran.
2. `package`, after JAR: resolve upstream SBOMs for dependencies whose content is not expressible in a `pom.xml`, and add their components with `isExternal` set to `true`.
3. `package`, after shade / assembly / WAR: set `isExternal` to `false` on the components that this step has physically embedded.

Would close #472 as a side effect.

Start by tracing how the current BOM is derived from the resolved dependency graph and how Maven's compile and package phases are handled. Implement the lifecycle stages described: record compile-time provenance, resolve upstream SBOM components after JAR packaging, and mark physically embedded components after shade, assembly, or WAR packaging. Done means the incremental output captures content not expressible in the POM and supports the stated isExternal transitions.

Written by the indexing model from the issue text.