[Image] Local `cq:actions` in Image v3 prevents parent `cq:childEditConfig` from applying in composite components

## Bug Report

**Current Behavior**
When the **Image v3** component is used as a child within a custom composite component (rendered using `data-sly-resource`), it does not honor the parent component’s `cq:childEditConfig` configuration of `cq:actions="EDITANNOTATE"`.
The goal of the composite component is to limit authors to edit-only actions on its children (Title, Text, Button, and Image). This configuration works correctly for **Title**, **Text**, and **Button**, but **fails for Image v3**.

Testing shows that Image v3 explicitly defines its own `cq:actions` in `_cq_editConfig`. When a child component defines local `cq:actions`, AEM overrides the parent’s `cq:childEditConfig`, preventing the parent from controlling editing behavior.
Image v3 is one of the very few Core Components that defines this property (besides Experience Fragment). Furthermore, the `cq:actions` values appear to duplicate AEM’s default behavior, making the definition redundant and problematic when Image v3 is used inside composite containers.

https://github.com/adobe/aem-core-wcm-components/blob/2a29cb8448b61fd9511da2cb82e02c3978ddce42/content/src/content/jcr_root/apps/core/wcm/components/image/v3/image/_cq_editConfig.xml#L3

**Steps to Reproduce**
1. Create a composite container component that includes a `_cq_childEditConfig` with `cq:actions="EDITANNOTATE"`.
2. Render several Core Components (Title, Text, Button, and Image v3) as children via `data-sly-resource`.
3. Open the page in the AEM page editor.
4. Select each child component.
5. Observe that only **Image v3** ignores the parent’s `EDITANNOTATE` restriction.

**Expected Behavior**
Image v3 should respect the parent’s `cq:childEditConfig` and restrict author actions to `EDITANNOTATE`, consistent with other Core Components.
If there is a valid reason for defining `cq:actions` in Image v3, that rationale and the expected impacts should be documented. Otherwise, the redundant property should be removed to ensure consistent behavior across Core Components.

**Environment**
- **AEM version:** AEM as a Cloud Service — **Release 2025.20.22943.20252009T135918Z**
- **Core Components version:** 2.30.2 (latest release)
- **Java version:** Java 11

**Possible Solution**
- Remove the explicit `cq:actions` definition from `_cq_editConfig` in Image v3 if it is not functionally required.
- If the definition is intentional, please clarify:
- The original rationale or use case for including it.
- The expected impacts or regressions if it were removed or overridden.
- Whether there are scenarios where the explicit `cq:actions` are required for authoring consistency or UI functionality.

**Additional Context**
In a composite setup, this issue prevents consistent control of authoring actions, breaking the intended editing restrictions.
A current workaround involves creating a **proxy component** for Image v3 and redefining `_cq_editConfig/cq:actions` as an empty string, which restores the expected behavior.

Related discussion: [Issue #1893](https://github.com/adobe/aem-core-wcm-components/issues/1893#issuecomment-983703596).
We acknowledge that **component composition in AEM** is a known challenge and naturally introduces some limitations.
However, this particular issue appears **avoidable** if the redundant `cq:actions` definition is removed or revised directly in the Image v3 component.

Start with content/src/content/jcr_root/apps/core/wcm/components/image/v3/image/_cq_editConfig.xml, especially the referenced cq:actions entry, and review related discussion in issue #1893. Reproduce the composite-component behavior in AEM with a cq:childEditConfig of EDITANNOTATE; done means Image v3 follows the parent restriction or the file documents why it must not.

Written by the indexing model from the issue text.