feat: add App.defaultConfig for bundled app config defaults

[arbrandes]

Description

App.config held two unrelated kinds of value: the defaults an app author bundles with the app, and the configuration an operator supplies through site.config or the runtime config API. Because both went through one field, every key an app bundled was a key commonAppConfig could never supply, and an operator overriding a single value had to spread the app's existing config back in or silently discard the rest.

This adds an optional App.defaultConfig for the app author's values. getAppConfig resolves it below commonAppConfig, which resolves below config. The two fields are held separately, so operator-supplied configuration, including anything arriving via the runtime config API, can never write into an app's bundled defaults.

The field is additive: an app that does not set it resolves exactly as it does today. Nothing in this repository bundles app defaults, so there was nothing to migrate. The migration how-to now points app authors at defaultConfig, and ADR 0017 records the decision.

Closes #268.

LLM usage notice

Built with assistance from Claude.

[brian-smith-tcril]

I do like the idea of adding the new app default config as a way to separate the concerns of "app author wants to set a default for something" and "site operator wants to override a site default for one app."

I'm now trying to think through the different configs, and it feels to me like we might be missing one:

Priority	Config	Purpose
0	???	Common defaults
1	App.defaultConfig	App defaults
2	commonAppConfig	Operator provided common
3	config	Operator provided app-specific

I know we have non-app "common" defaults in site config, and maybe that's a better place for anything that would fall into the "???" category to live, but I figured it was worth raising.

[arbrandes]

@brian-smith-tcril

non-app "common" defaults

That doesn't exist at the level of frontend-base or apps. It's something for the site, and we already have a place for it: commonAppConfig.