Reorder image and param checks

[mcourteaux]

Adding in a regression test that should have been part of #9333, revealed another issue with the alignment propagation.

When going the add_requirement() route, those asserts ended up below the ImageChecks asserts. So bounds inference (and thus none of those asserts) were aware of any of the user-specified preconditions.

I fixed this by peeling off the existing asserts before placing the injection markers.

Drive-by fix to have the generated string for a failed add_requirements() to actually print the condition, instead of the to-false-simplified failed condition expression.

Fixes #9328 again.

Breaking changes

Not really breaking: but the only test that broke was the one checking error codes under certain artificially constructed scenarios. Because the asserts are reordered, a few of those artificially constructed error scenarios were now failing on a reordered assert that in the original test came later.

Checklist

• Tests added or updated (not required for docs, CI config, or typo fixes)
• Documentation updated (if public API changed)
• Python bindings updated (if public API changed)
• Benchmarks are included here if the change is intended to affect performance.
• Commits include AI attribution where applicable (see Code of Conduct)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 69.80%. Comparing base (da06573) to head (608d23c).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #9337      +/-   ##
==========================================
- Coverage   69.96%   69.80%   -0.16%     
==========================================
  Files         258      258              
  Lines       78338    78349      +11     
  Branches    19066    19068       +2     
==========================================
- Hits        54806    54694     -112     
- Misses      17844    17846       +2     
- Partials     5688     5809     +121     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[abadams]

I don't think it's actually safe to assume the requirements outside the scope at which we know it's not a bounds query. When you're doing a bounds query you may pass buffers that do not obey requirements yet, and you expect the pipeline to, e.g. round up the stride of a buffer to satisfy the requirement and return it. set_stride(stride()/16*16) is not just a constraint. it's a recipe for how to make a buffer conform. This is why it's in the form of an assignment. If that expression is simplified by a requirement it's going to make Halide return a buffer that fails to obey the contraints. This is probably what's happening in the onnx test.

[mcourteaux]

So, add_requirements(f.extent.0 % 16 == 0) is not equivalent to f.dim(0).set_extend(f.dim(0).extent() / 16 * 16) in the case of bounds queries? Sigh.

[mcourteaux]

@abadams Do you think it's acceptable to execute the reordering (as in this PR) if bounds queries are disabled? It cleans up the asserts preamble massively if you have a few add_requirements().

[abadams]

The issue is that the add_requirement is strictly weaker. If you have code that uses that version, the minute you need a bounds query for some reason you need to change it to the other form anyway. There should be one way to do it. If the other form is ugly, maybe we need a method specifically to say "this extent/stride/min of this input/output buffer is aligned"