feat(declarative): explore opt-in array merging for configuration templates

> [!IMPORTANT]
> This issue records a feature request idea only. It is not approved or scoped
> for implementation.

## Summary

Explore optional array composition when a consumer uses `_extends`.

Today, consumer arrays replace inherited arrays entirely, as defined by #1976.
That behavior must remain the default for backward compatibility.

Conceptually, an explicit operation could allow a consumer to append to an
inherited array:

```yaml
policies: !append
- ref: consumer-specific-policy
```

The syntax and supported operations are intentionally undecided.

## Challenges and constraints

- "Merge" could mean append, prepend, set union, index merge, or keyed merge.
- Generic configuration templates expand before schema validation, so kongctl
cannot infer an array's identity key or semantics.
- Ordering, duplicates, removals, and repeated inheritance must be
deterministic.
- Existing semantics must remain unchanged:
- omitted array inherits;
- untagged array replaces;
- `[]` clears;
- `null` remains explicit.
- Behavior must compose safely with nested `_extends`, YAML tags, cross-file
templates, diagnostics, and sync-scope capture.
- Keyed merging would require explicit identity and deletion rules; implicit
index merging should not be used.

## Possible initial scope

If approved, consider explicit append/prepend operations only. Schema-aware or
keyed merging should require separate design and justification.

Related: #1774, #1976.

Start by reviewing #1976 and #1774, then trace how generic configuration templates expand before schema validation. No implementation is ready: first agree on the explicit syntax and semantics for append or prepend, including ordering, duplicates, nesting, diagnostics, and compatibility with existing array behavior; done would require an approved scope and corresponding tests.

Written by the indexing model from the issue text.