受け渡し口の前の見立ての確かめ（1006 の記録）。
ご指示の4番のとおり先に数えました。**一部が合っていないので、直さずに止めて報告します。**

════════════════════════════════════════════════════════
1. 数えた結果：2号機が受け渡し口の前で止まったとき、1号機は何をしていたか
════════════════════════════════════════════════════════

  受け渡し口の前（x 14.0〜15.8 / z 4.8〜6.6）で「もう1台のロボット」で止まった回数
      2号機 **182 回・1,143 秒**（1号機は 27 回。合わせて 209 回）
      1回あたり 中央 2.8 秒 / 最長 60 秒

  そのとき 1号機は
      配り終えて**戻る途中**              132 回（**73%**）
      **待機**（往復をしていない）          32 回（18%）
      出て行く途中（まだ1皿も届けていない） 18 回（10%）

  そのとき 2号機自身は
      出て行く途中  106 回（58%）
      戻る途中       76 回（42%）

  （「何をしていたか」は、その時刻がその台のどの往復の中か、
    皿が届いた時刻（trips.csv の dish_arrived_s）の前か後かで分けました）

════════════════════════════════════════════════════════
2. 見立てと合っているところ・違うところ
════════════════════════════════════════════════════════

**合っているところ（ここが主な原因です）**

  ・止まる場所の1位は受け渡し口の前。429 回のうち 209 回がここ
  ・相手は 91%（132＋32）が「戻ってきた台」か「待機場所にいる台」。
    待機場所が受け渡し口の右にあるので、**出て行く台と戻る台がここで交差します**
  ・2号機の 58% は「出て行く途中」。つまり
    **出発する台と戻る台が、受け渡し口の前で鉢合わせしている**

**違うところ（ここだけ、ご指示の文と事実が食い違います）**

  「料理を載せている台の前を通れない」という場面は **1回もありません**。
  Unity では **料理を載せる時間が 0 秒**だからです。
    ・common.load_s（15 秒）は下げ膳だけで使う値（v5 3章で確認ずみ）
    ・staffDwellAtPassSec も v5 3章で 0 にした
  どの台も受け渡し口で立ち止まらず、通り抜けるだけです。
  相手は「通り抜けている台（73%）」か「待機場所に止まっている台（18%）」でした。

  → **1番の「使っている台がいる間」の“使っている”が、いまの作りでは決められません。**
    止まっている時間が無いので、そのままでは「使用中」が 0 秒になり、何も変わりません。

════════════════════════════════════════════════════════
3. もうひとつ、お伝えしておくこと（0913 と 1006 の比べ方）
════════════════════════════════════════════════════════

  回数は増えましたが、**止まっていた時間は減っています**。

                        0913（cs:122）   1006（cs:123）
    「もう1台のロボット」   105 回          **429 回**
       その合計の秒数       5,375 秒        **4,505 秒**（−16%）
       動けなくなった       80 回           **50 回**（−38%）
    時間切れの往復         27 / 41         **24 / 45**
    立ち往生（rescues）     134             127
    全部の止まりの秒数      11,064 秒       11,445 秒

  1回あたりが長い止まり（60 秒で立ち往生）が、短い止まり（中央 2.8 秒）に置き換わりました。

  回数が増えた理由も分かっています。429 回のうち
    ・新しい譲り合いが働いたのは **22 回だけ**（cause_detail が「道をゆずって下がった」）
    ・356 回は、前のセンサーで相手を見て止まっただけ
  cs:123 の4番で「仕事が無い台は、料理が待っていても待機場所へ下げる」ようにしたため、
  **受け渡し口と待機場所の行き来が増え、交差の回数そのものが増えました**。
  私の直しが、回数が増えた主な原因です。

════════════════════════════════════════════════════════
4. 直す前に決めていただきたいこと
════════════════════════════════════════════════════════

  ご指示のとおり、ここで止めます。1番の「使っている」をどう決めるかだけ、お願いします。

  **案A（おすすめ）：受け渡し口の前を「予約」にする**
    ・受け渡し口の前の点から半径 passLockRadiusM（仮 1.2 m）を、1台だけが使える場所にする
    ・使い始め … 料理を割り当てられたとき（そこへ向かい始めるとき）
      使い終わり … 最後の点を出て、その半径から出たとき
      戻ってくる台も、受け渡し口の前に入る前に取る
    ・取れない台は、自分の待機場所で待つ（進まない）
    ・取れないまま passLockMaxSec（仮 30 秒）過ぎたら、取れたことにして進む（固まらないため）

  **案B：止める場所を分ける（予約を使わない）**
    ・2番だけを入れる。戻る台は受け渡し口の前の点を通らず、その少し下（z を passReturnOffsetM
      だけ下げた線）を通って右の待機場所へ抜ける
    ・出て行く台は今までどおり受け渡し口の前の点から出る
    ・交差そのものを無くす形。予約の仕組みが要らないぶん、作りが小さい

  2番の線は、どちらの案でも入れます。通れる床に乗っていることは、
  その線の上を 0.05 m 刻みで NavMesh.SamplePosition で確かめ、
  乗らない点が1つでもあれば線を使わず今までどおりにする（報告に出す）、という形にします。

  3番のとおり、値（passLockRadiusM・passLockMaxSec・passReturnOffsetM）は
  RobotSpec の「受け渡し口の前の通り方（Unity だけの決まり）」の欄1か所にまとめます。

  **案A と案B のどちらにするか**（または両方）を教えてください。決まり次第すぐ入れます。
