Enforce the review boundary by path

One repository holding the core and every host means one review queue unless scrutiny is
allocated deliberately. The shared core reaches every host at once, so a bad decision there
is expensive. A mistake in presentation is a contained bug on one screen of one platform.

The intent is that core paths get careful engineer review with the architecture agreed
before code is written, and presentation paths can move on lighter automated review.

This has to be mechanical, not cultural. The known failure mode is business logic
turning up in the areas that were only lightly reviewed, and a convention did not prevent
it. So: path-scoped ownership, review required on guarded paths, and CI that blocks a merge
when a guarded path is touched without it.

Which paths are guarded is a decision for the team, not something to infer, which is why
this is labelled for decision.

Steps

• Agree which paths are guarded
• Path-scoped ownership for those paths
• Review required on guarded paths
• CI blocks a merge when a guarded path is touched without the required review

Done when

Business logic cannot merge through a lightly reviewed path, enforced rather than observed
afterwards.