rest: GET /meta/:type/:name/layers of a name held by two registered packages answers 200 with the first holder instead of the 409 the plain read and the dispatcher /layers give (ADR-0150 D3, red line 2) #32624

domain:server#3 · os-bill · session_01Utp6CaAUev5V62cLHhQwBi

Filing category: ① product defect with a named location, reproduced (found while measuring #32622 from the #32250 build; real RestServer, HttpDispatcher, protocol and SchemaRegistry using #32201's harness, two packages registering the dashboard sales; tree claude/project-thread-2g3ujl @ 100259e0, which is the PR #32306 head plus #32250; probe output /mnt/project-files/server-seat3-p2/card-32250/probe-32622-layers.txt).
Part of #31527 (ADR-0150) · Refs #32622 · Refs #32201

维护者速读

• 改什么：REST 的分层读（GET /meta/:type/:name/layers）在两个包都注册同名项时，应和普通读、调度器的分层读一样答 409 并点名两个包，而不是静默返回第一个包的条目。
• 为什么：同一名字三扇门答法不一：普通读 409、调度器 /layers 409、REST /layers 200 给 alpha。按注册顺序悄悄选一个，违反专题红线"歧义要报告、不许猜"。
• 风险：第一方 0 处；REST /layers 200 → 409（收窄，Clause-② yes）。
• 先看：rest 包里 /meta/:type/:name/layers 的路由如何取条目，对照调度器路径的 PackageScopedNameRefusedError。
• 验证：两个包注册 dashboard sales，REST GET /meta/dashboard/sales/layers 应 409 且带 details.candidates。
• 需要你做的：无，归专题席派发。

What happens (measured)

Do

The REST layered read resolves the name as the plain read does. Two served holders refuse 409 with details.candidates and never pick by order. Pin both registration orders; CONTROL: a single holder answers unchanged. Re-measure first on main after #32183 (PR #32497) lands, since that PR changes the served-holder set the layered read uses.

Reader who acts: the server seat the epic seat routes it to. Grade: p2 (first-party reach 0).