fx_directory_rename does not update the ".." entry when a directory is moved to a different parent #98

Describe the bug
When fx_directory_rename moves a directory to a different parent directory, it writes the directory's entry into the new parent and marks the old entry free, but never updates the .. entry stored inside the moved directory itself. The .. entry keeps the starting cluster of the old parent.

• Target device: custom embedded board (ARM Cortex-A7, ThreadX, GHS toolchain). The defect is target-independent, though — it sits in portable common/src code and reproduces with any port, e.g. the Linux port with a RAM disk driver.
• Version: observed with FileX 6.4.0. Our copy descends from the azure-rtos/filex line (last upstream commit dated 2024-01-10, i.e. the same 6.4.0 release this repository's initial transition commit 1488480 was taken from — ours still with exFAT). Local additions on top do not touch the directory code. We have not run current master, but by reading the source the affected code path in 9da40d4 (v6.5.1.202602_rel) is unchanged.
• Toolchain: ghs multi_816, comp_201814

To Reproduce
Steps to reproduce the behavior:

1. Create the directories /A and /B, a marker file /A/SRC.TXT, a marker file /B/DST.TXT, and the directory /A/SUB.
2. Pre-check: open /A/SUB/../SRC.TXT — succeeds, .. resolves to /A as expected.
3. Move the directory: fx_directory_rename(&media, "/A/SUB", "/B/SUB"); — returns FX_SUCCESS.
4. Open /B/SUB/../DST.TXT — fails with FX_NOT_FOUND.
5. Open /B/SUB/../SRC.TXT — succeeds: --> .. still resolves to the old parent /A.

Expected behavior
After fx_directory_rename moves a directory to a different parent, the .. entry inside the moved directory names the new parent.

Impact
We cannot reliably implement recursive directory-walk operations, because after a directory move any traversal that relies on .. ends up in the wrong directory. We already have a patch that fixes the defect and would be glad to submit it as a pull request.