fix(monitoring): declare the bpmn-visualization webjar the Processes page loads

[delchev]

Fixes #6634.

resources-monitoring's Processes page loads
/webjars/bpmn-visualization/dist/bpmn-visualization.min.js at runtime
(js/services/processDiagram.js:13) to render the live BPMN diagram, but the module declared no
dependencies at all. The webjar reached the classpath only through ui-perspective-processes — that
is, through the Web IDE, which is the one thing this shell is explicitly built to work without.

So the single assembly the module is designed for is exactly the one where the diagram silently fails:
the <script> 404s, loadLibrary() rejects, and the pane stays empty. Nothing in the build catches
it, because the dependency is real in the full build/application and only missing from a curated
distribution.

The change

One dependency, on the module whose page loads it — org.webjars.npm:bpmn-visualization at the
existing ${bpmn-visualization.version}. This matches how application-core already works: it
declares the webjars its own pages load (alpinejs, codbex__harmonia, lucide, pinecone-router,
i18next, fontsource__open-sans) rather than relying on a sibling to bring them.

perspective-processes keeps its own declaration — it loads the same URL from
bpm-process-viewer.html.

Verification

• dependency:tree on resources-monitoring now resolves bpmn-visualization:0.47.0 directly, with
  its transitives (typed-mxgraph, es-toolkit, fast-xml-parser, mxgraph).
• dependency:tree on build/application still resolves it exactly once, at 0.47.0, with zero
  version-conflict warnings — so the full distribution is byte-for-byte unaffected and only a curated
  assembly gains anything.
• The webjar does contain the requested path (.../0.47.0/dist/bpmn-visualization.min.js, served
  version-lessly by webjars-locator — the same URL perspective-processes has been loading).
• mvn clean install green on the module.

Notes

The dependency carries a comment. Nothing in this module imports the webjar from Java, so it reads as
an unused dependency and would be a natural thing for someone to "clean up" — the comment records why
it is there.

Scope check while I was in here: resources-monitoring loads five webjar URLs. The other four
(alpinejs, codbex__harmonia, lucide, pinecone-router) are covered by application-core, which
any assembly containing the shared shell runtime must include anyway — so bpmn-visualization was the
only orphan. The sibling shells (resources-admin, -application, -personal, -partner) declare no
dependencies for the same reason and are fine as they are.

🤖 Generated with Claude Code