fix: canonicalize_nodes sometimes mangles the entrypoint

[acl-cqc]

closes #2262

The test seems fragile - i.e. somewhat lucky to have reproduced the bug in the first place - so I've included trying a bunch of cases that worked before (every possible entrypoint of the failing Hugr, and "hugr-1.hugr" and "hugr-3.hugr" i.e. the valid ones) as well.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.17%. Comparing base (ede8e7b) to head (806c08c).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2263      +/-   ##
==========================================
+ Coverage   82.15%   82.17%   +0.01%     
==========================================
  Files         239      239              
  Lines       42989    43012      +23     
  Branches    38901    38924      +23     
==========================================
+ Hits        35319    35346      +27     
+ Misses       5679     5675       -4     
  Partials     1991     1991              

Flag	Coverage Δ
python	85.34% <ø> (ø)
rust	81.84% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 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.

[zrho]

I think this should work, but I'm slightly confused why it's done this way.

If I understand this correctly, ordered can be seen as a map from new node id to old node id. Therefore the new entrypoint is the node with id target such that ordered[target] == self.entrypoint. You can do one check for this just after the let mut source = \\ ... line, before you follow the permutation chain. Am I missing something?

[acl-cqc]

I think this should work, but I'm slightly confused why it's done this way.

If I understand this correctly, ordered can be seen as a map from new node id to old node id. Therefore the new entrypoint is the node with id target such that ordered[target] == self.entrypoint. You can do one check for this just after the let mut source = \\ ... line, before you follow the permutation chain. Am I missing something?

Thanks - yes, you are right; ordered is not mutated (I've refactored to make that clearer). So the old check was kind of correct, if we had done it before following the permutation chain, rather than after. (I had been scratching my head over this a bit before, thank you for figuring it out!)

I've simplified using that, and made some of the logic a bit more explicit using an Option. And to increase confidence I've generalized the test to include more cases...how's that? :)

[zrho]

LGTM!