受注編集時の Order 全体に対する同時実行制御(楽観ロック)の導入検討

## 概要

PR #6903（Issue #6671 対応）にて、受注編集画面の二重送信による `OrderItem` 破損を防止するため、`EditController::isOrderUpdatedSinceFormRendered()` でフォーム描画時点の `update_date` と現在値を突合するチェックを追加した。

このチェックは「リクエスト2がリクエスト1のコミット後に読む」逐次的な二重送信ケースの `OrderItem` 破損を防ぐことに限定されており、`Order` 行に対するロック（行ロック/楽観ロック）は導入されていない。

そのため、「両リクエストがコミット前に読む」真の並行編集ケースでは、`update_date` チェックをすり抜け、通常の last-writer-wins（後勝ち上書き）が発生しうる。これは `OrderItem` の破損ではないが、管理画面での同時編集における一般的なデータ上書きリスクとして残存する。

## 対応内容（案）

- `Order` エンティティに `@Version` 等の楽観ロック機構を導入するか、更新処理時に `EntityManager::lock()` による行ロックを行い、同時編集の衝突を検出できるようにする。
- 影響範囲の洗い出しが必要:
- `src/Eccube/Service/PurchaseFlow` 配下の各種 Processor
- `Shipping` 関連の更新処理
- 管理画面での一括操作（バルクアクション）
- その他 `Order` を書き込むすべての経路

## 参考

- PR: https://github.com/EC-CUBE/ec-cube/pull/6903
- 該当コメント: https://github.com/EC-CUBE/ec-cube/pull/6903#discussion_r3534129571
- 起票依頼者: @ttokoro20240902

## 受け入れ条件

- `Order` に対する同時編集が検出でき、意図しない上書きが発生しないこと
- 既存の `PurchaseFlow` / `Shipping` / 一括操作等の既存動作に回帰がないこと
- 影響範囲に対するテストが追加されていること