config dump omits per-file overlays and inherited default-component-config

### Summary

`azldev config dump` presents itself as showing the *"fully resolved project configuration"*, but it stops at the file-level merge and does not run the per-component resolver. As a result, two important sources of effective configuration are invisible in the dump even though builds honor them:

1. **`overlay-files` expansion** — overlays loaded from `overlays/*.overlay.toml` (per-file overlay format, [docs](https://github.com/microsoft/azure-linux-dev-tools/blob/main/docs/user/reference/config/overlays.md#per-file-overlay-format)) never appear in `components..overlays`.
2. **Inherited `default-component-config`** — fields injected from project/distro/component-group defaults never appear on the concrete component.

Downstream commands (`build`, `render`, `prepare-sources`, `diff-sources`) *do* run the resolver (`applyInheritedDefaultsToComponent` → `ExpandResolvedOverlayFiles`), so the artifacts they produce are correct. The gap is display-only, but it makes `config dump` misleading as an authoring/debugging aid.

### Repro

Given a component using the per-file overlay format:

```toml
# base/comps/GraphicsMagick/GraphicsMagick.comp.toml
[components.GraphicsMagick]
overlay-files = ["overlays/*.overlay.toml"]
```

```toml
# base/comps/GraphicsMagick/overlays/0001-drop-libheif-build-dependency.overlay.toml
[metadata]
category = "azl-dep-missing-workaround"

[[overlays]]
type = "spec-remove-tag"
tag = "BuildRequires"
value = "libheif-devel"
```

Then:

```
$ azldev config dump -f json | jq '.components.GraphicsMagick.overlays'
null
```

But `azldev component list -p GraphicsMagick -O json | jq '.[0].Overlays'` shows the overlay, and `azldev component render -p GraphicsMagick` correctly removes the `BuildRequires: libheif-devel` line from the rendered spec.

### Impact

- Confuses users during authoring — a config that clearly "works" appears empty in the dump, prompting incorrect "my overlays aren't being applied" diagnoses.
- Blocks the documented pattern of using `azldev config dump -q -O json | jq ...` for ad-hoc queries about effective component config (works today only for fields authored inline).
- Makes the MCP `config-dump` tool less useful for coding agents that ask "what is the effective config for component X?".

### Suggested fix

Add a flag to `config dump` that runs the per-component resolver before serialization. Some options:

- **A (preferred):** `azldev config dump --resolved` (or `--expand`) — off by default to preserve today's round-trippable output; when set, iterates components through the resolver and replaces the `components` map with resolved copies (including expanded `overlays` and merged inherited defaults).
- **B:** Always dump the resolved view; drop the round-trippability guarantee. Breaking change; probably not worth it.
- **C:** Documentation-only — clarify in `Long` help and [config-file.md](https://github.com/microsoft/azure-linux-dev-tools/blob/main/docs/user/reference/config/config-file.md) that `config dump` is pre-resolver and point users to `component list -O json` for the resolved view. Cheapest fix but doesn't help the MCP-tool case.

Happy to send a PR for option A if the team agrees on the shape.

### Related code

- Dump entry point: `internal/app/azldev/cmds/config/dump.go` — marshals raw `env.Config()`.
- Resolver used by build/render/prepare-sources: `internal/app/azldev/core/components/resolver.go` — `Resolver.FindComponents` → `getComponentFromNameAndSpecPath` → `applyInheritedDefaultsToComponent` → `ExpandResolvedOverlayFiles`.
- Feature introduced by PR #256 (per-file overlays / inherited `overlay-files`); this gap has existed since then.