app:pack aborts when Node writes process warnings to api-mesh stderr

### Describe the bug

`app:pack` treats **any** output on the `aio api-mesh get --json` child process' stderr as a fatal error:

https://github.com/adobe/aio-cli-plugin-app/blob/master/src/commands/app/pack.js#L198-L202

```js
const { stdout, stderr } = await execa('aio', ['api-mesh', 'get', '--json'], { cwd: process.cwd() })

if (stderr) {
throw new Error(stderr)
}
```

Node process warnings are written to stderr while the command still exits `0`. On Node 22 the `punycode` deprecation (`DEP0040`) is emitted on essentially every `aio` invocation, so a **successful** mesh lookup aborts packaging, with the deprecation notice reported as the error.

The thrown message doesn't contain `Unable to get mesh config.`, so it falls through the classification below and is rethrown, failing the whole command.

### Steps to reproduce

1. Node 22 (`v22.22.2` here), `@adobe/aio-cli` 11.1.2, `@adobe/aio-cli-plugin-app` 14.8.1, `@adobe/aio-cli-plugin-api-mesh` 5.7.0 installed
2. Run `aio app:pack` in any App Builder project

```
- Getting api-mesh config...
✖ Command failed with exit code 1: aio api-mesh get --json
(node:42333) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
› Error: Command failed with exit code 1: aio api-mesh get --json
```

Confirming the warning goes to stderr on an otherwise clean run:

```console
$ aio api-mesh get --json 2>/tmp/err.txt >/tmp/out.txt ; cat /tmp/err.txt
(node:25694) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
```

### Expected behaviour

Node process warnings on the child's stderr should not be interpreted as an api-mesh failure.

### Note on the stderr check

The `if (stderr) throw` is not redundant and shouldn't simply be dropped — it is how the "no mesh" case is detected. `api-mesh:get` reports that via `this.error(msg, { exit: false })`, which writes to stderr and **exits 0**, so execa resolves:

https://github.com/adobe/aio-cli-plugin-api-mesh/blob/main/src/commands/api-mesh/get.js

The fix therefore needs to keep the check but exclude Node process warnings from it.

### Secondary bug in the same block

```js
if (err?.message.includes('Error: Unable to get mesh config.')) {
```

The optional chaining stops one level short. If a thrown value has no `message` — a non-`Error` throw, or an execa error carrying output only on `stderr` — this raises `TypeError: Cannot read properties of undefined (reading 'includes')` inside the catch, masking the original failure. This is currently asserted as expected behaviour in `test/commands/app/pack.test.js`:

```js
await expect(command.createDeployYamlFile(extConfig)).rejects.toEqual(TypeError('Cannot read properties of undefined (reading \'includes\')'))
```

### Environment

| | |
|---|---|
| OS | Linux 5.15 (Ubuntu) |
| Node | v22.22.2 |
| `@adobe/aio-cli` | 11.1.2 |
| `@adobe/aio-cli-plugin-app` | 14.8.1 |
| `@adobe/aio-cli-plugin-api-mesh` | 5.7.0 |

I have a fix ready and will open a PR referencing this issue.

Inizia in src/commands/app/pack.js, intorno alla chiamata aio api-mesh get --json, e leggi i test correlati in test/commands/app/pack.test.js. Mantieni il rilevamento del caso di stderr no-mesh gestendo al contempo gli avvisi del processo Node, e verifica che la mancanza dei messaggi di errore non mascheri più il fallimento originale. Esegui i test pack mirati e conferma che la ricerca riuscita del mesh procede su Node 22.

Scritto dal modello di indicizzazione a partire dal testo della issue.