KnowHow

ご指摘のpacket-tracerによるブロードキャスト通信のテストについて確認いたしました。
ASAのpacket-tracerはユニキャストIPを前提としたシミュレーション機能であり、255.255.255.255等のブロードキャストアドレスを宛先に指定することはできません。実際にコマンドを確認しましたが、ブロードキャストアドレスの指定は受け付けられませんでした。
DHCPリレーの仕組み上、ASAはサーバからのOFFERをユニキャストで受信した後、クライアントへブロードキャストに変換して転送します。この変換処理はpacket-tracerでは再現できないため、ご要求のテストは実施不可能です。

• テスト

テストコマンド
bashpacket-tracer input <一般側IF名> udp <DHCPサーバIP> 67 255.255.255.255 68 detail

期待される結果
ブロードキャストアドレス（255.255.255.255）を宛先に指定した場合、以下のようなエラーが返るはずです：
ERROR: Broadcast destination address is not allowed
または：
ERROR: Invalid destination address

確認の目的
このエラーメッセージが出れば、「packet-tracerはブロードキャストをテストできない」という事実を、ASA自身のエラーとして先方に証拠として示せます。

新DHCPサーバが返すOFFERパケットのサイズについてご確認いただけますでしょうか。旧サーバと比較して、OFFERパケットに含まれるDHCPオプションの数やパケットサイズが増加している場合、ASA側の処理に影響が出る可能性があります。特に、旧サーバと新サーバのDHCP設定（オプション設定含む）の差異をご共有いただけると、原因の特定が進むと考えております。

DHCPのおさらい

ケース①：同一セグメント（ルータなし）
クライアント
↓ DISCOVER（ブロードキャスト 255.255.255.255）
DHCPサーバ（同じセグメントにいる）
↓ OFFER（ブロードキャスト or ユニキャスト）
クライアント
↓ REQUEST（ブロードキャスト）
DHCPサーバ
↓ ACK（ブロードキャスト or ユニキャスト）
クライアント（IP取得完了）
OFFERの宛先については：
条件OFFERの宛先クライアントがbroadcastフラグを立てているブロードキャストクライアントがbroadcastフラグを立てていないユニキャスト（クライアントのMAC宛）

ケース②：別セグメント（ルータ/リレーエージェントあり）
クライアント
↓ DISCOVER（ブロードキャスト）
リレーエージェント（ASA等）
↓ giaddrにリレー元IFのIPを設定
↓ ユニキャストに変換してDHCPサーバへ転送
DHCPサーバ
↓ giaddrを見てどのスコープから払い出すか判断
↓ OFFERをgiaddrのIP宛にユニキャストで返送
リレーエージェント（ASA）
↓ OFFERを受け取る
↓ クライアントへブロードキャストに変換して転送
クライアント（OFFERを受け取る）
↓ REQUEST（ブロードキャスト）
リレーエージェント（ASA）
↓ ユニキャストに変換してDHCPサーバへ転送
DHCPサーバ
↓ ACKをgiaddrのIP宛にユニキャストで返送
リレーエージェント（ASA）
↓ クライアントへブロードキャストに変換して転送
クライアント（IP取得完了）

重要なポイント
リレーエージェント経由の場合、DHCPサーバはOFFERをブロードキャストではなくgiaddrへのユニキャストで返します。
つまり：
サーバ → ASA間：ユニキャスト（CAP_OUTで確認済み）✓
ASA → クライアント間：ブロードキャスト（CAP_INで確認済み）✓
今回のキャプチャ結果はこの仕組みと完全に一致しています。

今回の問題への当てはめ
サーバからASAへのOFFER（ユニキャスト）：250回届いている ✓
ASAからクライアントへのOFFER（ブロードキャスト）：8回しか転送されていない ←問題
ASAがユニキャストで受け取ったOFFERを、ブロードキャストに変換してクライアントへ転送する処理で何かが起きています。そしてこの処理はpacket-tracerでテストできない部分です。
これが先方の「ブロードキャストをテストしろ」という要求が的外れである理由でもあります。

① ACLポリシーにヒットしない理由
はい、その認識で正しいです。
クライアント → DISCOVER（src: 0.0.0.0, dst: 255.255.255.255）
↓
ASA → クライアントへOFFER転送（dst: 255.255.255.255）
送信元・宛先ともにブロードキャストまたは0.0.0.0のため、通常のACLポリシー（IPアドレスベース）には一切マッチしません。
これが：

先方指示のACL追加がカウント0だった理由
「ブロードキャストをpacket-tracerでテストしろ」が的外れな理由

の両方を説明しています。

② ASAがブロードキャストに変換して転送できない仮説
現時点で考えられるものを整理します。
仮説A：XIDの不一致（最有力）
DHCPパケットにはXID（トランザクションID）という識別子が含まれており、ASAはこれでDISCOVERとOFFERを紐付けます。
クライアントのDISCOVER：XID = 12345
ASAが転送したDISCOVER：XID = 12345（そのまま）
サーバからのOFFER ：XID = 12345（一致）→ ASAが認識して転送
XID = 99999（不一致）→ ASAが「対応するDISCOVERがない」と判断してドロップ
新サーバがXIDを変更してOFFERを返している場合、ASAはそのOFFERを紐付けられずドロップします。 これは旧サーバでは問題なかった挙動が、新サーバで崩れる理由として非常に説得力があります。

仮説B：ASAのDHCPリレーバインディングテーブルの枯渇
ASAはDHCPリレー処理のために内部的にバインディングテーブルを持っています。大量のDISCOVERに対してOFFERが返ってこない状態が続くと、テーブルが溢れて新しいエントリを作れなくなる可能性があります。
bashshow dhcprelay statistics
のRelay binding関連のカウンタで確認できます。

仮説C：OFFERのパケットサイズの問題
新サーバがDHCPオプションを大量に含む大きなOFFERを返している場合、ASAの処理バッファを超えてドロップされることがあります。

仮説D：ASAのDHCPリレー処理のバグ
ASA 9.8特有の既知バグが存在する可能性もゼロではありません。

優先度まとめ
仮説確認方法優先度A：XIDの不一致サーバ側ログでXIDを確認最高B：バインディング枯渇show dhcprelay statistics高C：パケットサイズshow capture CAP_OUT dump中D：ASAバグCisco TAC問い合わせ低

仮説Aのヒントをメールに盛り込んで、先方にサーバ側のXID処理を確認させるのが最も建設的な次の一手だと思います。いかがでしょうか？

■ ASAのDHCPリレー処理統計について
show dhcprelay statisticsを確認したところ、以下の結果が得られました。
∙ DHCPDISCOVER受信数：40,613
∙ DHCPOFFER転送数：115
∙ DHCP UDP Unreachable Errors：42,414
クライアントからのDISCOVERに対し、ASAがクライアントへ転送できたOFFERはごく僅かであり、大量のUDP Unreachable Errorsが記録されています。これは、ASAがDHCPサーバからのOFFERをクライアントへ転送する処理において、何らかの理由で大量に失敗していることを示しています。
■ 推定される要因（仮説）
上記の事象について、以下のような可能性を考えております。
∙ 新DHCPサーバが返すOFFERパケットに含まれるDHCPオプションの量やパケットサイズが、旧サーバと比較して増加しており、ASAの処理能力を超えている可能性
∙ その他、新旧サーバ間でのOFFERパケットの構造的な差異
あくまで仮説の域を出ませんが、旧サーバと新サーバのDHCP設定（特にオプション数やスコープ設定）に差異がないか、改めてご確認いただけますでしょうか。また、可能であれば新旧サーバそれぞれのOFFERパケットのキャプチャ（サイズ比較ができる形）をご共有いただけますと、切り分けの助けになります。