[Fix][DLight] Decline matmul schedules with unsupported consumer chains

[Edwardssss]

Fixes #20615

Problem

A fused conv2d -> bias -> ReLU -> output-padding function reaches the GPU Matmul rule, but the output-expanding consumer cannot be inlined into its cache-write stage. Consumer inlining is best effort; remaining consumers are an unsupported scheduling case, not an internal invariant violation.

Previously, auto_inline_consumer_chain asserted that all consumers had been inlined. This aborted ApplyDefaultSchedule before subsequent rules could run. An additional producer's explicit compute_inline could also raise a ScheduleError instead of declining the schedule.

Changes

• Return a boolean from auto_inline_consumer_chain indicating whether all consumers were inlined.
• Catch only s_tir.ScheduleError around the additional producer's explicit compute_inline; do not wrap the entire rule or suppress programming errors.
• Return None from both generic Matmul and MetalMatmul when the helper fails, preserving DLight's existing rule-dispatch contract.
• Add five regression cases covering supported bias/ReLU consumers, unsupported output padding, unchanged input on decline, subsequent default-rule scheduling, and a non-inlineable reduction producer.