Extend config.d.ts @visibility guidance to entity provider packages in boost AGENTS.md

What happened

On PR #4574, the code agent added security-sensitive fields (caData, skipTLSVerify, apiKey) to the ogx-entity-provider plugin but omitted @visibility backend annotations in its config.d.ts. The review agent flagged this as a medium-severity secrets-exposure finding (review run 34520203260). The fix agent addressed it in commit 03280e5, adding the missing annotations.

The boost workspace AGENTS.md has a detailed "Adding new config fields" section (lines 136–160) that explicitly requires @visibility annotations, but it is scoped to plugins/boost-backend/config.d.ts and the centralized Zod schema system. Independent entity provider packages (ogx-entity-provider, kagenti-entity-provider) maintain their own config.d.ts files outside this system, so the code agent did not apply the guidance when working on ogx-entity-provider.

The review agent also noted that the ogx-entity-provider config.d.ts only declared 4 of the ~9 fields that readOgxEntityProviderConfig actually reads, and flagged isValidPem as duplicated from boost-connector-utils/src/ca-bundle.ts rather than reused.

What could go better

The code agent could have gotten the config.d.ts right on the first attempt if the AGENTS.md guidance covered all packages that declare config fields, not just boost-backend. This would have avoided the review finding, the fix agent iteration to add annotations, and the subsequent re-review — saving approximately one review-fix cycle (~$10–12 in agent costs).

Confidence: high. The code agent demonstrably reads and follows the boost AGENTS.md "Adding new config fields" section (the initial PR included a changeset, config examples, and API report updates as that section instructs for boost-backend). Extending its scope to entity provider packages is straightforward and directly addresses the gap.

Proposed change

In workspaces/boost/AGENTS.md, below the existing "Adding new config fields" section (after line 160), add a subsection:

### Config declarations in entity provider packages

The `ogx-entity-provider` and `kagenti-entity-provider` packages each
maintain their own `config.d.ts` (they do not use the centralized Zod
schema system in `boost-backend`). When adding or modifying config
fields in these packages:

1. Declare **every** field that the package's config reader function
   reads (e.g., `readOgxEntityProviderConfig`) in the package's
   `config.d.ts`. Backstage uses `config.d.ts` for config validation
   and visibility enforcement — undeclared fields bypass both.
2. Add `@visibility backend` to any field that holds secrets or
   security-sensitive data (API keys, certificates, TLS bypass flags).
   Add `@visibility secret` to fields that must never appear in
   frontend config (e.g., `apiKey`).
3. Check `boost-connector-utils` for reusable TLS and HTTP utilities
   (`isValidPem`, `createHttpsAgent`, `safeGetOptionalString`) before
   implementing equivalents locally.

Validation criteria

The next code agent PR that adds or modifies config fields in ogx-entity-provider or kagenti-entity-provider should include complete config.d.ts declarations with appropriate @visibility annotations for all security-sensitive fields on the initial commit, without requiring a review-fix cycle to add them.

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

Read the existing “Adding new config fields” section in workspaces/boost/AGENTS.md, especially lines 136–160, then review the proposed scope for ogx-entity-provider and kagenti-entity-provider. Update the guidance so their config.d.ts files, visibility annotations, complete declarations, and boost-connector-utils checks are covered. Done means the documented rules match the validation criteria for future config-field PRs.