ADR-17: 名前解決は premise 相対である。曖昧なときのみ上位存在で修飾する

判断: 名前（monthEnd・Following・TSE 等）は、現在の premise の下でのみ値に解決される遅延参照とし、 premise から切り離された絶対的意味を持たない。ある premise 集合の下で名前が一意に解決できるなら裸で書け、複数の解釈があり得るなら上位存在（暦法・軸・名前空間）での修飾を強制し、無修飾は静的エラーとする。上位存在は、省略の有無にかかわらず別途宣言されねばならず、その宣言が曖昧判定の前提条件をなす。

背景: 同じ綴りが premise で別物に解決される場面は、この言語に構造的に存在する。monthEnd は暦法相対（グレゴリオ暦と会計暦で別の日）、Following は軸相対（日軸と時刻軸で判定根拠が違う。ADR-13 の軸非依存の裏面）、TSE は asof 相対（年により祝日集合が違う。ADR-15）。ゆえに名前解決は premise 相対でなければならず、これは ADR-16「意味は premise 相対」が値だけでなく名前にまで及ぶ帰結である。解決の定石は VB のモジュール修飾名（Module1.Foo）や SQL のスキーマ修飾（sales.orders）に既にあり、「一意なら裸、曖昧なら修飾」という枯れた規則をそのまま採れる。

ただし SQL/VB との決定的な差が一つある。SQL の名前が曖昧かどうかはスキーマ一覧から静的に確定するが、本言語の monthEnd が曖昧かどうかは「どの暦法が premise に載っているか」に依存する。context calendar-system: Gregorian だけなら一意、Gregorian, Fiscal2026 の二つが載れば同じ monthEnd が曖昧化する。すなわち曖昧性そのものが premise 依存で発生する。この判定を可能にするのが「上位存在は別途宣言必須」であり、宣言された premise 集合が確定して初めて、名前が一意か曖昧かを機械的に判定できる。

却下した案:

暦法ごとに常に別名を強制し、名前を常時一意にする案（Gregorian.monthEnd を必須）。曖昧さは原理的に消えるが、一意な場所でも修飾が要り「一行で書きたい」志向と正面衝突するため却下。
同名衝突時に premise の優先順で暗黙に一方を採る案。取り違えがサイレントな誤結果を生むため却下（I3 違反）。

帰結:

名前解決は三層。予約語（言語キーワード。固定・文脈非依存・ユーザ名と衝突禁止）／文脈非依存のユーザ名（@TSE のような単なる値への別名・糖衣）／premise 相対の名前（monthEnd・Following 等・上位 premise の下でのみ解決される遅延参照）。
名前空間は、衝突回避（レベル 1）だけでなく「どの premise での解釈か」を担う器（レベル 2）を兼ねる。暦法が名前空間を成し、同じ綴りが各空間で別の値に解決される。
本 ADR は ADR-16 の特殊ケースである。名前もまた供給されるべき premise の一つであり、複数候補があって選べないことは「未解決」の一種として同じ静的エラー規律に服する。新しい公理は追加していない。