ADR-001: Position-aware defaults and config seeding

[UltraBob]

@mandclu I think it makes sense to start out by putting some ADRs in place for the unification. I'll be opening some PRs for these against a 2.x branch. Please check these, and express any concerns about the approaches, assumptions, or ideas in them. (or just make edits)

Hopefully that gets us onto the same page about the approach and the user experience. Then we can try to have an agent power the actual merging. In this one, I've deviated a little from the original idea of setting a mode at install. Now the installer will ask (and you could run the installer again to do both) whether you intend to maintain a site or a contrib module(s). Based on your answer we will either seed config files for the whole site, or offer to give you some starter configs in your module director(ies). Actual code quality tooling runs will mostly be based on your current directory when you run the command.

Summary

• Replace the proposed DCQ_PROJECT_TYPE mode switch with position-aware runtime defaults via HostWorkingDir: true
• Installer asks site vs contrib; site seeds configs with custom-path directives, contrib relies on the cascade
• Contrib maintainers get an explicit seed command for opt-in config pinning
• The config IS the mode: wrappers check config existence and content, never a mode variable

This is the keystone decision for the merge. Review order 1 of 10: all other ADRs may reference this one, but this one stands alone.

Review checklist

• Does the position-aware approach cover your workflow?
• Is the site/contrib installer question clear enough?
• Does the contrib seed-on-request model work for module maintainers?

[mandclu]

Instead of this being an install-time decision, could it offer to add config files based on where it is run?

e.g. the first time run run it in the root directory, it will offer to add config files for the site, and the first time you run it within a module it would offer to add config files to the module