Discuss: stack version support policy for integration packages

## Context

Raised by @andrewkroh in https://github.com/elastic/integrations/pull/16985#discussion_r3102458914: when a package adopts a new `package-spec` feature (post-format_version 3.4), it must narrow `conditions.kibana.version` to exclude stack versions that don't support the feature. Users on those older stacks are then stuck on the prior package version with no clear path to bug fixes.

This will recur with every major stack version. 8.19 is the first concrete case where a flagship package (AWS) is hitting it. Resolving this now sets the pattern.

## Current state (data)

- [55 packages on format_version 3.5](https://github.com/search?q=repo%3Aelastic%2Fintegrations+path%3A**%2Fmanifest.yml+%22format_version%3A+3.5%22&type=code)
- [5 packages on format_version 3.6](https://github.com/search?q=repo%3Aelastic%2Fintegrations+path%3A**%2Fmanifest.yml+%22format_version%3A+3.6%22&type=code)
- Remainder on 3.4 or earlier

The 55 packages on 3.5+ have effectively committed to narrower `kibana.version` ranges. Many have already dropped 8.19 with no shared guidance, no backport path, and no user-facing communication beyond the version constraint itself.

**The implicit policy today is:** bump `format_version` + narrow `kibana.version` = users on older stacks stay on the prior package version indefinitely. Teams make this call package-by-package.

## What's not happening

- No team maintains parallel major-version branches per package (the overhead is prohibitive and nobody has signed up for it).
- No mechanism exists for a single package version to ship conditionally based on stack version.
- No documented policy on when narrowing `kibana.version` is acceptable vs. when a package should hold back feature adoption.

## Questions for the ecosystem team

1. Is the implicit policy ("narrow `kibana.version`, older users stuck on prior version") the intended model?
2. If yes, should it be documented so teams stop making the call silently?
3. If no, what's the alternative - and who owns building it?
4. Should flagship/high-install-base packages have different guidance than long-tail packages?

## Related

- elastic/package-spec#997 - proposes build-time validation of `format_version` ↔ `kibana.version`. That's a mechanism; this issue is the policy question upstream of it.
- elastic/package-spec#228 (closed, 2022) - raised a similar question without a landed resolution.
- elastic/package-spec#230 (open, 2022) - older version-constraint discussion.

Scope is deliberately broader than #997: this issue is about what the policy *should be*, which #997 could then enforce.

## Note

elastic/integrations#16985 is being handled separately by the Cloud Security team - not blocking on this discussion. This issue is about the broader pattern.