bugfix: reconcile max_seqs_per_batch with max_concurrent_requests.

[Kang-Meng]

• Align the scheduler batch cap and the service admission cap at
  startup in initialize_configs(): min when both > 0, the non-zero
  one when one is 0, LOG(FATAL) when both are 0. Downstream users
  (Master, Engine, BlockManagerPool, RateLimiter, ProfileManager)
  now see the same effective cap on both fields.
• Drop the scheduler default from 1024 to 200 so it matches
  ServiceConfig::max_concurrent_requests out of the box (keeps the
  gflag DEFINE_* and the PROPERTY in-class default in sync per
  custom-code-style §10).
• Fix VLM and Rec engines silently dropping max_seqs_per_batch
  when building BlockManagerPool::Options -- the SINGLE block pool
  was falling back to a 2-slot capacity (1 padding + 1 usable),
  effectively capping concurrent sequences at 1 on those paths.
• Tighten a few unit tests that relied on the pool default being
  0 by setting .max_seqs_per_batch(0) explicitly, so the intent to
  drive the SINGLE pool from num_single_blocks alone stays local
  and does not depend on Options' default value.

[yingxudeng]

目前 cicd npu 失败，请补充本地 npu 通过所有单测的截图