ModelJars 0.1.43

Fixed

• The Granite 4.1 3B Q4_K_M marker could not be used in 0.1.40–0.1.42. Its jar carries a qualification file from before the catalog's launch target was corrected, stamped with the same generatedAt as the corrected bundled catalog, so the registry refused both with Conflicting RAG qualification catalog metadata at the same generation instant. With that marker on the classpath every ModelJars call failed, including calls for other models. The bundled catalog now carries a later generation instant and wins; the published marker is unchanged and opens.
• Qualification prompt templates resolve to runtime chat templates. The Granite RAG qualification records the harness envelope granite-documents, which is not a runtime chat template id, so the runtime would have rejected it next. It now maps explicitly to granite (identical user and assistant turns; only the documents block differs). Unknown templates still fail loudly.
• The CLI Spring Boot configuration for Granite now writes chat-template: granite.

Guards

• The build fails if any bundled RAG or tool qualification names a template the runtime cannot render.
• A test loads the qualification file from the published Granite marker jar beside the bundled catalog.
• A CI gate fails any qualification-manifest change that does not advance generatedAt.

Added

• modeljars coordinates <model> --spring-boot | --spring-ai and modeljars demo <model> --spring-ai | --spring-boot (#157).
• Generation profiles and computed memory-fit tables in modeljars show and on modeljars.org (#156).

Verified end to end: the unchanged Granite marker from Maven Central opens on Models 0.3.40 and generates text; all 45 published markers load and resolve their templates.