[wimi321]

MPSGraph compiles a new executable the first time graph.encode sees a new set of input shapes. The search varies the batch size from call to call, so every batch size not seen yet stalls all search threads while it compiles. That is about 3 s each for the b11 transformer (kata1-tf3-b11c768-s12002M) on an M4 Pro.

Restarting a search (a new kata-analyze, or moving to another position) makes the next batches small. So a GTP session hits several of these stalls in its first minutes, then never again. Running macOS sample during a stall shows:

• the MPSGraphExecutable_queue thread in mlir::collectRegions;
• every search thread waiting in NNEvaluator::evaluate.

When KataGo sizes the batch itself, this PR uses the existing FixedShape batch policy for Metal, the same way the ONNX backend does with onnxPadBatch:

• With no nnMaxBatchSize in the config, getBatchPolicy returns FixedShape. The default nnMaxBatchSize becomes about half the concurrent evals (computeFixedShapeMaxBatchSize), which the Metal section of the example configs already recommends.
• GPU (MPSGraph) handles then run every batch at nnMaxBatchSize and discard the extra rows. Padding rows copy row 0, since an all-zero row has an empty mask.
• A configured nnMaxBatchSize keeps Dynamic batches. It is usually sized for dynamic batching (analysis_example.cfg sets 64), and padding every batch up to it multiplies the work (second table below).
• ANE (CoreML) handles evaluate row by row and never pad.
• metalPadBatch = true pads a configured size too, and metalPadBatch = false restores the previous behavior. Both are documented in gtp_example.cfg and analysis_example.cfg.

GTP measurement setup:

• one start, then 24 stop + kata-analyze restarts on one midgame position, alternating with and without focus;
• b11 network, M4 Pro;
• a minimal GTP config: numSearchThreads as listed, and every batch setting left at its default.

	stalls after startup	first visits after start	visits/s
master, 8 threads	5	6.1 s	57
this PR, 8 threads	0	3.1 s	54
master, 6 threads	3	6.0 s	55
this PR, 6 threads	0	3.1 s	55
this PR, metalPadBatch = false	5	6.0 s	58

Padding to the Dynamic default size instead (8 rows) halved throughput (29 visits/s), which is why the batch is sized the FixedShape way.

Analysis engine: analysis_example.cfg (nnMaxBatchSize = 64) with numSearchThreadsPerAnalysisThread = 1, the first 80 positions of one game sent as separate 2-visit queries, kata1-tf3-b11c768-s12002M, M4 Pro:

	80 queries	first result
master	6.8 s	2.9 s
first commit of this PR (padded to the configured 64)	212.1 s	6.7 s
this PR	6.8 s	2.9 s

With the second commit, the 6-thread GTP run still has no stalls (first visits 3.1 s, 54 visits/s), and with nnMaxBatchSize = 16 set it behaves like master (3 stalls).

testbackendreference (b11) passes, with error statistics matching master to within 0.00003, and runnnlayertests passes. I measured on arm64 only. The change also builds on an Intel (x86_64) macOS runner, where we ship it in our own engine build, but I had no Intel Mac to measure on.