Decide where the design-conventions doc lives, and who writes it

What surfaced

#416 wrote the design branch into commands/specs.md. #404 decided that the plugin says only "a path is declared" and left the doc itself unlocated, so #416 decided two things in passing and this issue is where they are written down rather than settled by the first reader who needs them.

1. Where the doc lives. /specs derives it from the config value: docs/agents/<design.type>.md, the value lower-cased, beside the tracker contract. Measured against the Consumer — design.type: figma on DXP-DesignSystem's develop, and #414 writes docs/agents/figma.md — so the derivation matches today. It costs no new config key and compares nothing to a literal. The alternative is an explicit design.conventions path key, which /setup would then have to ask for and README § Configuration reference would have to carry.

2. Nobody writes it. /setup lands six artefacts and this is not one. A Consumer with a design system and no doc meets the requirement at /specs' halt — the command stops, prints the path, and says to write it or set design.type to none. The tracker contract had exactly this shape until #383 gave it a writer, and every Box in a fresh Consumer printed BLOCKED until then.

The decision

• Does the doc keep the derived path, or gain a config key?
• Does /setup write it, scaffold it, ask for it, or leave it to the Consumer? The install set's ownership rule would make it a tenant-owned file: written on a first run, reported on thereafter.

Why it is not urgent

The one Consumer has the file. This bites the second Consumer, or the first one that renames its design system.

Read commands/specs.md, the /setup behavior, README § Configuration reference, and the linked issues #404, #416, #414, and #383. Compare the derived-path and explicit-config alternatives, then document the decision and align the affected command and configuration documentation so the ownership and first-run behavior are unambiguous.