fix(resolve-extends): always resolve extended parser presets for proper merging (#4647)

* fix(resolve-extends): always resolve extended parser presets for proper merging

When a user provides a partial parserPreset (e.g. only issuePrefixes),
the extended config's string parser preset was skipped because
loadExtends checked !context.parserPreset before resolving. This meant
the extended preset's headerPattern was never loaded, so it got lost
during the config merge.

Two changes fix this:

1. Remove the !context.parserPreset guard in loadExtends so string
   parser presets from extended configs are always resolved, making
   their parserOpts available for merging.

2. Preserve user-provided properties during the nested parserOpts
   unwrapping in loadParserOpts. Previously the unwrap replaced the
   outer object entirely, dropping any user additions that were merged
   at that level during config resolution.

Fixes #4640

* fix: address review feedback from qodo and copilot

- Shallow-copy the dynamicImport result to avoid mutating an immutable
  ESM namespace object when assigning the resolved parserPreset.
- Add explicit type cast in load-parser-opts destructuring so inner
  is Record<string, unknown> instead of unknown.
- Clarify unit test scope: it covers the merge path while the
  integration test covers string-to-object resolution.