chore(defaultconfig): curate the shipped default + add extension capability

[thomasboni]

What this PR does

Two user-facing improvements to how Plumber is configured.

1. A safer, cleaner default

The shipped default .plumber.yaml is now curated so a project's first scan catches real supply-chain and hardening problems without a flood of false positives. The same default is used everywhere: a zero-config run, plumber config generate, and the plumber config init wizard all produce a consistent posture, so there is no drift between them.

2. Customize without owning the whole file

Until now, changing one setting meant copying the entire configuration and maintaining all of it yourself. You can now keep a small file instead.

Add extends: plumber:default at the top of your .plumber.yaml and list only what you want to change. Everything else is inherited from Plumber's baseline, and new checks that Plumber ships are picked up automatically. A file without extends keeps behaving exactly as before, so existing configs are unaffected.

For trusted-source lists (GitHub Actions and container registries), includePlumberDefaults: true (the default) keeps Plumber's curated list and adds your entries on top. Set it to false to trust only your own entries.

Example:

extends: plumber:default
github:
  controls:
    githubActionMustComeFromAuthorizedSources:
      trustedGithubActions:
        - my-org

New config commands

• plumber config generate --overlay writes a short starter overlay instead of the full file.
• plumber config resolve prints the complete effective configuration, useful to review it or commit a fully explicit version.
• plumber config view --explain shows, per control, whether a value comes from the baseline or from your file.
• plumber config slim turns an existing full configuration into a minimal overlay.

Closes #375.

[github-actions]

All Claude review controls completed on the latest revision.

[thomasboni]

@Joseph94m ready for review

[Joseph94m]

@thomasboni
First question:
is the extends implemented in a way so that in the future, users will be able to write:
extends: plumber:/local/default/config/path or extends: plumber:/remote/git/path ?

I don't mean that the feature should work now but does the code make it easy or difficult on us to do that change? Because I can see the feature coming.

---

Second question:
does extends plumber:default refer to the in-memory config only? Or any config that is discovered automatically by plumber such as plumber.yaml or passed through the --config flag ?

If its not just the default config / automatic ones that are taken as bases, then I am not sure if the name should be default or something else like extends plumber:base ?

---

Third question:

This is just to verify that my understanding is correct.
I have this setup: a default .plumber.yaml an overlay.yaml in the same repo. I run

plumber config view --explain and i get the follow results. It shows that everything comes from an overlay because we didn't specify a --config? So it takes the .plumber.yaml and fully ignores the overlay.yaml ?

Alternatively when running ./plumber config view --explain --config overlay.yaml i get :

Which seems to work because i only overlayed the actionsMustBePinnedByCommitSha control

---

Fourth Question:

plumber config slim is confusing to me. Its doc says

./plumber config slim --help
Collapse a full .plumber.yaml into a small overlay that extends
plumber:default, keeping only the controls whose values differ from the
baseline. Comments are not preserved; the result is a fresh minimal file.
Review it, then commit. Use 'plumber config resolve' to expand it again.

But isn't the .plumber.yaml the default? so shouldn't the output be empty?

[thomasboni]

@Joseph94m

1. Current code make this future implementation easy, no refactor will be needed
2. Extends refer to the in-memory config only, nothing else. We keep the name plumber:default, it means Plumber shipped default. base is more generic and can get ambiguous if multiple extend sources exist
3. yes for your both questions: it shows that everything comes from an overlay because you didn't specify a --config, so it takes the .plumber.yaml and fully ignores the overlay.yaml
4. .plumber.yaml is not the default, it's your config. If it's the same to the default, then yes slim's output will be empty. Slim exists for the case where the file is a full copy that has drifted across versions