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().