Cross-ecosystem constraint algebra: widen VersionScheme with intersect/compatible?

[JPDuchesne]

Context

The constraint standard (docs/deps-architecture.md, PR #142) is a shape plus an interpreter: every constraint is a dev-shaped hash whose keys the integration's VersionScheme owns, minted by repositories at the find seam. There is deliberately no universal constraint grammar — semver, PEP 440, gem requirements, and buildids don't unify, and translating vocabularies would be a lie.

Problem

Real solving needs more than satisfies?/sort. Diamond dependencies (and #147's constraint accumulation on already-resolved packages) require combining several constraints on the same package: today the resolver can only check candidates against one constraint at a time, so joint satisfaction across a graph is unrepresentable.

Proposal

Grow cross-ecosystem capability by widening the scheme algebra, never by translating vocabularies:

• VersionScheme#intersect(a, b) — the constraint (in the same vocabulary) satisfied exactly where both inputs are, or an explicit empty/contradiction result.
• possibly compatible?(a, b) as the cheap decision form.

Each scheme implements the algebra over its own vocabulary (SemverScheme over node ranges, Pep440Scheme over specifiers, PinnedScheme trivially: equal-or-contradiction). The Resolver then accumulates constraints per PackageId and re-checks the chosen version on each new edge — the backtracking-solver path the decision gate in docs/deps-architecture.md already anticipates.

Notes

• Records the standing decision: shape + per-integration interpreter; dev-native territory defaults to SemVer.
• Prereq for honest diamond handling in Resolver silently skips constraint checks on already-resolved transitive edges #147 and for the sub-lock preference idea in Feature: prefer sub-lock pins as solver preferences (conservative resolution) #148.