Enforce dependency visibility between common sub-modules via pants

Goal: enforce the intra-common dependency direction between sub-modules with pants visibility rules instead of documentation only. For example, common/schema must not depend on common/dto, while dto may depend on schema.

Background: common/ is currently a single pants target (//src/ai/backend/common:src, one python_sources globbing \***/**.py). Pants visibility is target-level, so dependency edges between sub-modules that live inside the same target (schema<->dto, types, etc.) are not checked at all. The component-level visibility_private_component in common/BUILD only blocks common from importing upper layers (manager, etc.); it cannot distinguish sub-module directions within common.

Discovered during BA-6666: deployment strategy schemas were moved into a new common/schema module whose AGENTS.md states "schema must not depend on dto". That rule currently cannot be machine-enforced under the single-target structure and remains a documented convention only.

Scope: split the relevant common sub-modules (schema, dto, types, and others as needed) into separate pants targets with their own visibility rules, so directional rules between them are enforced by pants check. Decide the target granularity and the allowed dependency matrix between common sub-modules.

Reference: BA-6666 (Remove strong coupling of the manager models layer).

JIRA Issue: BA-6777

Start with common/BUILD and the common/AGENTS.md rules described in the issue, then inspect how the single //src/ai/backend/common:src target globs Python files. Define the target granularity and allowed dependency matrix for schema, dto, types, and other sub-modules, then run Pants check to confirm the directional visibility rules are enforced.

Written by the indexing model from the issue text.