Support frontend boundary rules for style ownership and local CSS escape hatches

[PerishCode]

Requested-By-Repo: PerishCode/mini-stim
Requested-By-Branch: feat/mini-stim-product-next

Problem

Some frontend codebase constraints are not implementation details and are not
pure design taste either. They are repository-level boundary rules:

• where styling is allowed to exist
• where styling must not exist
• which layer owns reusable style expression
• which layer is forbidden from adding local style escape hatches

Today these constraints often live in AGENTS.md, project docs, or review
conversation. That keeps the intent visible, but it does not make the
constraint durable.

Why this fits flavor

This class of constraint has a few stable properties:

• it is architectural, not page-local
• it is repeatable across changes
• it is usually machine-checkable
• violation means a real boundary regression, not just a style preference

Examples:

• apps/client/soma/web must not grow page-level .css or .scss files
• business-layer React code must not use inline style
• web routes/pages must compose styling through atoms/components instead of
  inventing local style rules
• frontend package boundaries may prohibit direct imports from lower-level
  ownership layers

These are exactly the kinds of constraints that drift if they remain only as
human convention.

Scope boundary

Not every SCSS-related desire should become a hard rule.

There is an important split between:

1. Hard boundary constraints
2. Human design/implementation judgment

The first group seems well-suited for flavor:

• no page-level CSS in a forbidden directory
• no inline style in a forbidden layer
• no direct import from disallowed ownership layers
• required file pairing or directory ownership rules

The second group likely should remain outside hard enforcement:

• whether a SCSS abstraction is elegant
• whether BEM usage is tasteful enough
• whether a layout atom split is the best possible one

Those are still useful review criteria, but they are not the same kind of
constraint.

Request

It would be valuable if flavor explicitly treated this style of frontend
boundary rule as a first-class use case, rather than assuming its scope is only
backend/module structure.

The core request is not a specific syntax proposal yet. The request is to
recognize and support repository-level frontend boundary enforcement such as:

• forbid CSS/SCSS in selected directories
• forbid inline style usage in selected directories
• enforce ownership boundaries between frontend layers
• support other similarly objective style-location and boundary checks

Concrete motivation

In mini-stim, constraints like "web must not become a styling escape hatch"
and "style expression belongs in atoms/components, not page-local CSS" are
important product-boundary rules, not just implementation preference.

They feel like a natural fit for flavor because they are stable, objective,
and regression-prone if left only to docs and review.