Split Variable at Definition is unreliable with stack variables

Version and Platform (required):

• Binary Ninja Version: 5.1.7913-dev
• Edition: Non-Commercial
• OS: macOS
• OS Version: 15
• CPU Architecture: x64

Bug Description:
Splitting stack variables doesn't seem to work reliably. Many times it will only create a new variable at the current assignment, with all other references are stuck at the original variable. And since non-assignment references can't be split, there seems to be no way to fix this.

See below for a sample.

Steps To Reproduce:
Please provide all steps required to reproduce the behavior:

1. Load the database provided below.
2. Right click on var_948 at 0xc20 and select "Split Variable at Definition".
3. Reply "Yes" to the warning that "This variable appears to have dependencies that prevent it from being split safely."
4. The assignment now becomes var_948_1 but no other references to var_948 are updated, for example the one at 0xc40.

Expected Behavior:
I'd expect (at least some) subsequent references to var_948 now refer to var_948_1.

Screenshots/Video Recording:
n/a

Binary:
See proud castle paints happily.

Additional Information:
These might be enhancements, but two things that would help here are:

1. Some way to see the "dependencies that prevent [a variable] from being split safely." I tried to look at the MLIL and HLIL debug reports, but there's no way to search for var_948 in the graphs, so I couldn't see if they might have helped.
2. The ability to specify a scope for the redefinition. This may ultimately be a special case of UDIF that is needed to help the decompiler automatically detect the scope, in which case the above would help me figure out what variables I need to clarify. On the other hand, this might be an enhancement to splitting: rather than split all following references, split only the references that can only be reached following this assignment.

Load the database described in the issue and reproduce the "Split Variable at Definition" action on var_948 at 0xc20, then compare references such as the one at 0xc40. Start by examining the decompiler's variable-splitting and dependency handling; done means eligible subsequent references use var_948_1 while unsafe references remain justified and covered by regression testing.