Long path through multdiv into IF stage

Nobody has claimed this yet.

During his Zbt work #746 @ganoam noted that there is a long path from the register_file -> *multdiv* -> alu -> ex_block/branch_decision_o -> controller -> IF stage.

The strange thing is that while the path through multdiv and alu is expected (we use the adder for divisions), the combined path should never end up in the controller, branch decision, IF (these ops only depends on the alu). So my suggestion was to qualify the branch decision in the controller with an early signal (the branch decision should never matter if we are doing a multdiv). But this did not really help.

Maybe @tomroberts-lowrisc or @GregAC have some ideas?

The timing report can be found [here](https://github.com/ganoam/ibex/blob/bitmanip-devel-zbt/reports/bitmanip-zbt-pr/33bitshifter_adderbinmux_optimized/RV32B0_3stage_btalu_2_ns/post_synth_timing.rpt).

Start with the linked post-synthesis timing report and trace the register_file → multdiv → alu → ex_block/branch_decision_o → controller → IF path. Read the relevant pipeline and branch-decision logic to determine why multdiv operations still reach the controller and IF stage. Done means the multdiv timing path no longer includes that unnecessary combined path, with the result confirmed in a timing report.

Written by the indexing model from the issue text.