fix(verify)!: inline implementsのrefinement_failedをtop-level成功・exit 0で返す

[rizumita]

Problem

An inline implements refinement can return refinement_failed while both
fslc check and fslc verify keep a successful top-level result and exit code 0.

This is a false green: a consumer that follows the documented process-exit contract or reads only
the top-level result accepts a requirements layer that does not refine its business contract.

Environment

• release: fslc 4.4.1
• latest main: dbbf6889a0c1f3001552952ffc537632a01f8188 (also reproduced)
• observed on: macOS arm64

Minimal reproduction

override-business.fsl:

business OverrideBusiness {
  actor Operator
  entity Item

  process Item {
    stages Ready, Done
    initial Ready
    transition finish Ready -> Done by Operator
  }
}

verify { instances Item = 1 }

override-broken-requirements.fsl:

requirements OverrideBrokenRequirements {
  process Item {
    stages Ready, Done
    initial Ready
    transition finish Ready -> Done by Operator
  }

  implements OverrideBusiness from "override-business.fsl" {
    maps auto
    action finish(c) -> stutter
  }
}

verify { instances Item = 1 }

The implementation action changes the mapped abstract item_stage, but is declared as stutter.

$ fslc check override-broken-requirements.fsl --strict-tags
{
  "result": "ok",
  "implements": {
    "result": "refinement_failed",
    "violation": {"kind": "stutter_changed_abs"}
  }
}
$ echo $?
0

$ fslc verify override-broken-requirements.fsl --depth 2 --strict-tags --no-cache
{
  "result": "verified",
  "implements": {
    "result": "refinement_failed",
    "violation": {"kind": "stutter_changed_abs"}
  }
}
$ echo $?
0

Expected

A failed inline refinement makes the whole command non-successful:

• top-level result must not be ok / verified; and
• process exit must be 1 (property/contract not satisfied), or another documented non-zero class.

The nested violation should remain available as evidence.

Acceptance criteria

• check fails closed when inline implements.result == refinement_failed.
• verify fails closed for the same condition.
• Top-level result, nested result, and process exit cannot contradict each other.
• A valid maps auto control remains successful.
• Native full-envelope and exit-code tests cover both controls.

[rizumita]

#1002 と #1003 は1つのトラックで直す必要がある（controller が実測して確認）

両 issue を fslc 4.4.1 で再現した（scratchpad の同一2ファイル）。

実行	exit	top-level result	implements
check ... --strict-tags	0	ok	refinement_failed / stutter_changed_abs
verify ... --depth 2 --strict-tags --no-cache	0	verified	refinement_failed / stutter_changed_abs
同上 + --instances Item=1	0	verified	キーが存在しない

#1003 は #1002 の修正を迂回する経路である

#1002 だけを直すと（implements.result == refinement_failed で fail closed にする）、
--instances を1つ渡すだけでその判定が発火しなくなる。 #1003 のとおり implements フィールドが
封筒から消えるため、fail-closed の条件が「存在しない」からである。

⇒ #1002 の修正が完全に見えるまま、フラグ1つの迂回路が残る。 #1002 単独の修正は
偽の完了になる。

帰結

• fix(verify): --instances指定でinline implementsを省略する#94回帰 #1003 を fix(verify)!: inline implementsのrefinement_failedをtop-level成功・exit 0で返す #1002 と同じトラックで、fix(verify): --instances指定でinline implementsを省略する#94回帰 #1003 を先に（または同時に）直す。
  refinement が常に走る状態にしてから、失敗を fail closed にする
• 受入条件に 「--instances / --values を付けた場合も implements が評価され、
  失敗が非ゼロ exit になること」 を両 issue に共通で持たせる
• fix(verify)!: inline implementsのrefinement_failedをtop-level成功・exit 0で返す #1002 の !（破壊的変更）は exit code 契約の変更なので、結合変更が発火する:
  docs/LANGUAGE.md / docs/LANGUAGE.ja.md / 該当 docs/DESIGN-*.md / changelog.d（changed）/
  封筒と exit code の両方を assert する native test / exit code を pin している既存テストの全数確認
• 迂回路の negative control を持つこと: 「--instances を付けても壊れた refinement が
  検出される」を判定する検査。fix(verify): --instances指定でinline implementsを省略する#94回帰 #1003 の受入条件の最後の項目がそれに当たる

[rizumita]

裁定: fail closed に変える

現行挙動は docs/LANGUAGE.md:2152-2159 に意図的な例外として明記されている。 逐語:

That verdict is reported only in this field. It is not folded into the top-level result or the
exit code, so a broken seam still returns result:"ok"/"verified" and exit 0 — the one exception
to the exit-code table above, and the reason implements has no row in it. Gate on
implements.result == "refines", or run fslc chain ... Standalone fslc refine does exit 1 on
refinement_failed; only the inline seam is silent.

したがってこの issue は「実装が文書に違反している」ではなく 「文書化された意図的な例外を破棄する」 変更である。作者裁定として 破棄する（fail closed にする）。

根拠

1. AGENTS.md の非交渉項目が「Do not allowlist verdict, location, assurance, or exit-code drift」と明記している。壊れた seam が exit 0 を返す例外は、まさに allowlist された verdict drift である
2. standalone fslc refine は既に refinement_failed で exit 1 を返す。 同じ verdict に対して公開経路2本が不一致で、これは fix(kernel): requirementsの空relation初期化がcheck成功・kernel export失敗になる #1000（check と kernel が同じリテラルの型で不一致）と同じクラスである
3. 回避策（nested field を gate する / fslc chain を使う）は、exit 契約をそのまま読む消費者には届かない。 文書化された回避策の存在は、既定が偽 green であることを正当化しない

範囲と結合変更

• 破壊的変更として扱う。 現在 exit 0 で通っている壊れた seam を持つ spec は exit 1 に変わる
• docs/LANGUAGE.md と docs/LANGUAGE.ja.md の当該記述（上記逐語と exit code 表）を書き換える。
  implements の行を exit code 表へ入れる
• ⚠️ impl_violated は現行の exit-1 一覧に無い（一覧は violated / reachable_failed / unknown_cti / unknown_budget / nonconformant / refinement_failed / sweep_failed / observed_mismatch）。top-level が impl_violated を採るなら表への追加が必要である
• docs/DESIGN-design-family.md の同規則も同伴させる
• changelog.d は changed（破壊的変更）
• exit code を pin している既存テストの全数を機械的に列挙し、変わるものを1件ずつ判定する。 期待値を実装に合わせて書き換えず、なぜ以前の値が誤りだったかを書く
• fslc chain の既存挙動は変えない（既に exit 1 を返す）

#1003 との順序

controller のコメント（先報）どおり #1003 を先に直す。 #1003 を残すと --instances 1つで fail-closed 判定が発火しなくなる。2つの stacked PR とし、#1003（非破壊）→ #1002（破壊的）の順で出す。

[rizumita]

同クラスの残余を #1009 として切り出した

fslc html は run_verify_from_source の status を _ に束ねて破棄しているため
（rust/fslc/src/main.rs:11745）、violated な spec でも exit 0 を返す。
これは本 issue と同じクラスの偽 green だが、

• inline implements 固有ではなく、dbbf6889 の時点で既に violated に対して起きている
• html はレポート生成コマンドで、docs/LANGUAGE.md:1025-1027 は分析出力
  （explained / analyzed）を exit 0 の行に置いている

ため、本 issue の要求が名指ししていないコマンドへ破壊的変更を広げず、#1009 として分離した。

残スコープ: #1009（html）/ #1008（--property / --exclude-properties / --from-state の
無音省略）/ #1010（#94 の受入テストが native を守っていない）