Add Backstage catalog-model utility preference to ai-integrations AGENTS.md

What happened

On PR #3956, the code agent implemented OCI validation by manually splitting type:target location-ref strings with indexOf(':'). This manual parsing did not trim whitespace before comparing the type component, causing leading whitespace on a backstage.io/source-location annotation to silently skip OCI validation. The human reviewer (comment) identified that parseLocationRef from @backstage/catalog-model handles trimming, error cases, and type/target extraction correctly — it is the standard upstream utility for exactly this purpose. The fix agent then adopted parseLocationRef in commit 5b65088, resolving the issue. If the code agent had used parseLocationRef from the start, the whitespace bypass bug and subsequent fix rounds would have been avoided. The ai-integrations AGENTS.md has no mention of preferring upstream Backstage utilities.

What could go better

The code agent had no guidance to prefer upstream @backstage/catalog-model utilities over manual implementations. The workspace AGENTS.md covers build commands, architecture, and spec conventions but does not mention the standard Backstage catalog-model utilities that plugins in this workspace should use. This is a high-confidence gap: parseLocationRef, ANNOTATION_SOURCE_LOCATION, parseEntityRef, and similar utilities are foundational to Backstage plugin development and are used throughout the monorepo. Instructing the code agent to prefer these would prevent a recurring class of bugs where manual string parsing misses edge cases the upstream utility handles.

Proposed change

Add a "Backstage conventions" section to workspaces/ai-integrations/AGENTS.md instructing the agent to prefer upstream @backstage/catalog-model utilities over manual implementations. Specifically:

1. When parsing location references (e.g., backstage.io/source-location annotation values), use parseLocationRef from @backstage/catalog-model instead of manual type:target string splitting.
2. Use the exported constants ANNOTATION_SOURCE_LOCATION, ANNOTATION_LOCATION, etc. from @backstage/catalog-model instead of defining local string constants.
3. When parsing entity references, use parseEntityRef / stringifyEntityRef from @backstage/catalog-model.
4. Before implementing custom parsing for any Backstage-convention string format, check @backstage/catalog-model exports for an existing utility.

Example addition to AGENTS.md:

## Backstage conventions

Prefer upstream utilities from `@backstage/catalog-model` over manual implementations:
- `parseLocationRef` for `type:target` location-ref strings
- `ANNOTATION_SOURCE_LOCATION` / `ANNOTATION_LOCATION` for annotation key constants
- `parseEntityRef` / `stringifyEntityRef` for entity ref strings

Before writing custom parsing for Backstage-convention string formats, check `@backstage/catalog-model` exports.

Validation criteria

On the next 3 code agent PRs in the ai-integrations workspace that involve Backstage location refs or entity refs, the code agent uses upstream utilities from @backstage/catalog-model instead of manual string splitting. Zero instances of manual type:target parsing when parseLocationRef is available.

Generated by retro agent from https://github.com/redhat-developer/rhdh-plugins/pull/3956

Start with workspaces/ai-integrations/AGENTS.md and review its existing guidance sections. Add the proposed “Backstage conventions” section covering parseLocationRef, annotation constants, parseEntityRef, stringifyEntityRef, and checking @backstage/catalog-model before custom parsing. Done means the documented guidance addresses the listed utilities and avoids manual type:target parsing when parseLocationRef is available.