xpkg_dir treats a bare version as a literal pin while xlings matches it against four-segment keys, so a declared payload is installed and then reported absent #712

Observed

For one declared version, xlings and mcpp resolve different payloads.

• xlings first looks the requested version up as a literal key. On a miss, it parses the version as a range and compares with a three-segment floor, so 1.7 or 12.9.1 selects a four-segment key such as 1.7.0.1 or 12.9.1.4 (openxlings/xlings src/core/semver.cppm, the Eq constraint).
• mcpp (xpkg_payload_at, src/xlings/xlings.cppm:941-951) tries the literal directory first. It treats any version without an operator as a pin and returns nothing when that directory is absent.

Reproduction (mcpp 2026.9.26.2):

[xlings.workspace]
"xim:libglvnd" = "1.7"

// build.mcpp
mcpp::warning(("xpkg_dir(xim, libglvnd) = [" + std::string(mcpp::xpkg_dir("xim", "libglvnd")) + "]").c_str());

Provisioning [xlings.workspace] entries (xim:libglvnd@1.7)
warning: pinrepro: xpkg_dir(xim, libglvnd) = []
$ ls …/xpkgs/xim-x-libglvnd
1.7.0.1

xlings installs a payload for the declaration, and mcpp then reports that none is installed. The comment above xpkg_payload describes this same asymmetry for ranges, which was fixed there. For pins it remains.

The index uses the fourth segment as a packaging revision (fontconfig 2.15.0.1, libglvnd 1.7.0.1, llvm-dev 20.1.7.1, the CUDA libraries). A consumer who writes the upstream version therefore meets this case directly.

Request

One answer to "which payload does this declaration name". Either mcpp asks xlings which version it selected, or mcpp applies xlings's grammar: literal key first, then the three-segment floor, taking the highest match.