Run VSUM builds asynchronously and cache artifacts per input fingerprint

Right now every call to /build/check, /build/artifact or /build/bundle kicks off a full build in the setup-service and waits for it inside the HTTP request. There is no caching anymore: VsumService.getJarfat goes straight to SetupServiceApiHandler.buildVsumJarOrThrow, and the fingerprint cache we used to have (BuildCoordinator.runOncePerKey) was dropped in 5e7b2410 when the setup-service was wired in. So clicking download twice means building the generated Maven project twice, a minute or two each time.

Doing it synchronously also has some side effects. The setup-service call has a 300s timeout and buffers the whole artifact in memory (up to 500 MB) for each request, so a couple of users downloading at the same time is already a memory spike. On the frontend the only feedback is a spinner in CanvasPage; if the build is slow the tab just hangs, and a reload throws the build away. And we keep no record of anything, so there's no way to tell what was built, whether it failed, or to get a previous artifact back.

I'd like to turn builds into proper jobs:

• POST /api/v1/vsums/{id}/builds starts one and returns 202 with a build id. Builds run on a bounded executor, one per VSUM at a time.
• GET .../builds/{buildId} gives the status (queued / running / succeeded / failed), timestamps and the setup-service error if it failed. GET .../builds lists the history.
• GET .../builds/{buildId}/artifact and /bundle download the jar or the deployment bundle of a finished build.
• Inputs get fingerprinted (ecore, genmodel and reaction bytes plus the setup-service version). If the fingerprint matches the latest successful build we hand that back instead of building again; force=true bypasses it.
• A vsum_build table holds the metadata and points at the artifact in FileStorage, with some retention (keep the last N per VSUM).
• The three existing GET /build/* endpoints stay as blocking wrappers around create-or-reuse, so the current frontend keeps working; we can mark them deprecated in the OpenAPI docs. Showing build status in the UI would be a separate frontend issue.

Done means: two downloads with unchanged inputs trigger exactly one setup-service build, changing a file (or force=true) triggers a new one, a failed build is visible as failed with its message while the last good artifact stays downloadable, and the request that starts a build returns immediately. Access rules are the same as getJarfat today.

Related: #7 / #331 (the deployment bundle is one consumer of the jar) and vitruv-tools/Vitruv-CLI#42, which would fit nicely on top of a build history.