Extract VPC peering import direction as a tested renderer contract

[chet]

The overlap-safety work needs the same answer as the existing Ethernet Virtualizer renderer: for a given peering policy and receiver/peer virtualization types, does the receiver import the peer's prefixes? That decision currently lives inside rendering code and should not be reimplemented inside a new routing-safety subsystem.

Scope

• Extract the existing peering-direction decision into one small pure helper next to the renderer that owns the behavior.
• Keep the renderer as an authoritative production caller.
• Name the inputs and output around route import, not around future overlap implementation details.
• Cover the complete policy × receiver type × peer type matrix with table-driven tests.

Acceptance criteria

• Exclusive, Mixed, and None behavior is covered for every supported receiver and peer virtualization type.
• Existing rendered network behavior is unchanged.
• The helper has no database, configuration, admission, or lifecycle dependency.
• A later route-policy admission PR can reuse the contract without duplicating renderer logic.

Out of scope

• Prefix-overlap admission.
• VPC peering persistence or lifecycle changes.
• A shared routing_safety.rs module.

Dependencies

• Blocked by: None.
• Enables: Route-consumer admission under Enforce overlap eligibility and route-consumer safety atomically #3890.
• Parallel work: Overlap configuration, the transaction lock, and force-delete fencing.

Reference implementation and test corpus: #4940. Part of #3890 and #3883.

[chet]

The focused extraction pass showed that this should not be a standalone code change. The renderer already owns the authoritative behavior through the VpcPeeringPolicy match and the virtualization capability model's peers_with relation. The proposed helper produced the same vector as the existing inline code, added two production-unreachable policy arms, and duplicated the capability matrix tests.

I’m closing this slice instead of landing an abstraction before it has a real second caller. The small stale-comment correction can travel with #5114, where the route-policy admission path will provide the actual reuse point. This keeps the replacement series smaller and avoids recreating the same premature-centralization problem that caused #4940 to be closed.