docs: consolidate design rationale into contributing architecture and conventions

[gbrlcustodio]

Why

The design rationale was spread across three documents. It mixed durable rules with a snapshot of module paths. A snapshot goes stale, and a coding agent reads these documents as current. A stale sentence then becomes a wrong instruction.

The form was the second problem. A contributor who asked what to do here had to read a paragraph and extract the rule from it.

Outcomes

• One map of the architecture. It states the quality requirements and the constraints that shape the code. It draws the boundary, and it decomposes the code into applications, packages, and layers.
• One rule reference. Each rule carries a permanent ID, so a review cites the ID instead of the paragraph. A retired rule keeps its ID.
• Every requirement that shaped a decision on the map carries a row, in the terms of the consumer who holds it. The rows split by whether a requirement competes for effort. A competing one carries a rank, and a requirement that no release trades carries none.
• A section that serves a requirement names that requirement back. If no section serves it, Known gaps names it. Both directions therefore resolve.
• Every deviation from the map gathers in Known gaps. Each entry names the artifact that closes it, so the entry disappears when we enable that artifact.
• The map follows the arc42 template. A reader who knows that template knows where to look.
• Where a check enforces part of the map, the section names that check. The map prefers a check over a sentence, because a sentence can go stale and a check cannot.
• Two documents leave the tree, and the pointers to them follow. This PR preserves no prose verbatim, so a line-by-line comparison of the diff will not help.
• This PR changes documentation only. No code path and no test path changed.