feat: [DevOps] Add API compatibility check to spec-update workflow

[rpanackal]

Context

AI/ai-sdk-java-backlog#370.

Adds japicmp to detect breaking Java API changes when service teams update their OpenAPI specifications. This prevents spec changes from silently breaking SDK users by catching binary/source incompatible modifications to generated code.

Problem: Previously, the spec-update workflow only failed if code generation or compilation failed. Breaking changes to classes/methods/fields not covered by tests went undetected — resulting in breaking SDK releases.

Solution: After generating new code from an updated spec, japicmp compares the newly built JAR against a baseline JAR built from main. If any public API surface changed in a binary or source incompatible way, the workflow fails and reports the details.

Feature scope:

• Add japicmp plugin to parent pom.xml (<pluginManagement>)
• Enable japicmp in all generated modules with per-module <includes>:
  • core — core.client, core.model
  • orchestration — orchestration.model
  • document-grounding — grounding.client, grounding.model
  • prompt-registry — prompt.registry.client, prompt.registry.model
  • sap-rpt — foundationmodels.rpt.generated
• Add "Build baseline JAR" step to spec-update.yaml (uses git worktree for origin/main)
• Add "API compatibility check" step (runs japicmp, fails on incompatibility, reports .md to job summary)
• Add MODULE_PATH output to download step (single source of truth for service→module mapping)
• Report API compatibility status in PR body and job summary table

Definition of Done

• Functionality scope stated & covered
• Tests cover the scope above (tested by running the workflow itself)
• Error handling created / updated
• Aligned changes with the JavaScript SDK
• Documentation updated
• Release notes updated

[CharlesDuboisSAP]

Could you open a PR with breaking changes on one of the spec repos so we can see what the error would look like

[rpanackal]

Could you open a PR with breaking changes on one of the spec repos so we can see what the error would look like

Unfortunately, I can't until we merge this. I tried it forgetting the same fact and these results.

• PR in grounding repo
• spec update run

Though the test run proved as an example of the problem where there are multiple breaking changes and nothing was caught without some additional measure

[CharlesDuboisSAP]

Unfortunately, I can't until we merge this. I tried it forgetting the same fact and these results.

You could modify the workflow on your PR of document grounding, which would call the modified workflow your branch test/spec-update-japicmp