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.

Start in src/commands/app/pack.js around the aio api-mesh get --json call and read the related tests in test/commands/app/pack.test.js. Preserve detection of the no-mesh stderr case while handling Node process warnings, and verify that missing error messages no longer mask the original failure. Run the focused pack tests and confirm successful mesh lookup proceeds on Node 22.

Written by the indexing model from the issue text.