Fix #3960: RTAI module unload order

[grandixximo]

Summary

• Fixes the RTAI module-unload ordering reported in Module unloading issue - RTAI Master #3960.
• hal_lib inserts new components at the head of comp_list_ptr, so do_unloadrt_cmd traversal produces comps[] in newest-to-oldest order. The original loop then walked the array tail-to-head, which unloads oldest first. RTAI's rmmod refuses to remove a module while a newer one (e.g. motmod) still references it, producing the cascade of failures Andy reported.
• Uspace dlclose has no in-use check, so this latent ordering bug never surfaced on uspace or RT-PREEMPT (which uses uspace mode).
• Switched the iteration direction so comps[0] (newest) is unloaded first.

Test plan

• Builds cleanly under uspace (RT-PREEMPT-style).
• Sanity-checked on uspace: linuxcnc sim/axis start/stop, no new errors.
• Needs verification on RTAI: clean shutdown of axis_mm with no rmmod failed cascade. cc @andypugh — I don't have an RTAI environment to test this directly.

[grandixximo]

@NTULINUX if you have an RTAI box handy, could you give this a try? Just need to start axis_mm and shut it down cleanly, then check the terminal for any rmmod failed or "in use by" errors. Should be silent with this patch.

I don't have RTAI here so I can't verify it myself.

[andypugh]

I will try to remember to test this (very busy at the moment, getting a new kitchen this weekend...)
I seem to recall that we have previously switched the order for this problem before.
07cee88

Has the load order switched again?

[grandixximo]

@andypugh good catch, that is exactly the previous attempt at this. The codebase load order has not changed since then, the iteration polarity was just flipped the wrong way in #3443.

@BsAtHome's intent in that PR was right: "modules need to unload in reverse order from insmod insertion order." The catch is that hal_lib inserts new components at the head of comp_list_ptr (hal_init in hal_lib.c, line 275), which has been the invariant essentially forever. So when do_unloadrt_cmd walks the list to build comps[], comps[0] is already the newest component, and forward iteration (n=0..n++) is already the reverse of insmod order.

#3443 changed the iteration from forward to backward, believing backward was the reverse of insmod. But because the underlying list is already newest-at-head, that change actually flipped it from "newest first" to "oldest first," which is what triggers the RTAI cascade now. My patch puts it back to forward iteration.

I have updated the comments around both the build loop and the unload loop to explain the head-at-newest invariant explicitly and to call out the trap, including a pointer to #3443 so anyone tempted to "reverse" this in the future will think twice.

No offense intended @BsAtHome, this one was easy to misread, the code did not document the list ordering at all.

[grandixximo]

@BsAtHome are you already thinking along these lines: flipping comp_list_ptr to insert-at-tail (with a tail pointer so it stays O(1)) and make "unload in reverse insmod order" mean what it reads like? Not asking for it...

[NTULINUX]

I did a RIP build and did not have any issues unloading on RTAI, thanks!