Repository: godot
Issue: Inspector wont display variable correctly once its type changes
Labels: topic:gdscript,topic:editor,needs testing

### Tested versions

v4.3 dev5 - v4.2.1 stable

### System information

v4.3.dev5.official.89f70e98d - Vulkan 1.3.242 - Forward Mobile - NVIDIA - NVIDIA GeForce GTX 1650

### Issue description

## Description
It seems that the remote inspector has a bug whenever you change the value of a variable and the new value is of a different type. (And it also seems that this bug only appears when this assignment happens based on user interaction, like pressing a button.)

So the most basic version of this bug can be found when swapping a string with `null`, for example.
![image](https://github.com/godotengine/godot/assets/93130991/fd948666-3bc9-4885-b17a-4c2c17721ffe)
As you can see in this image, the values are set as we would expect by default. I also did not yet press `ui_accept` yet, so it is correct that the values are not changed yet. But then: 
![image](https://github.com/godotengine/godot/assets/93130991/0b06354d-4070-4a51-ba62-b8e728634234)
As you can see, the print has been run to confirm that I pressed enter. Even the `controll_value` changed, but that is only there to show that the inspector does update. 
BUT!!, situation1 does not update in the inspector (even though when you print it, it has indeed updated).
Because it started with null, its field in the inspector is not the same type of field as the field that is needed to display strings.
And my guess is that that is the reason why the string can't be displayed now. 
And situation2 is here to even further show that, since that was origionally a string, so that started with a string field in the inspector. And you can still see it has a different field, even though it is now null (the 2 situations are both null but both have different fields).
![image](https://github.com/godotengine/godot/assets/93130991/f30ea14a-454d-4c7e-a9b6-58558b7eb788)


#### Note that this happens with almost everything that you try if it has the 2 following conditions:
1. its assignment is activated by user input
2. its assignment is between 2 different types (`null` included)
So, this bug appears for forexample: int to string;  int to bool; bool to string,
also your own Resources or nodes.

even int en floats combined. This is even more interesting
If you start with a variable that is an int.
`var my_number = 12` and then asign it with a float/decimal number
`my_number = 3.42` then what will happen is that in the inspector tab, it will not change the field type, so it will show `3`, so it rounded the decimal in the inspector.
(even though it is saved corectly, so doing `print(my_number)` will print 3.42)

Note that telling what type the variable is does not do anything to prevent this bug.
It indeed fixes the problem for most basic types since if you give them a type, they can only be that type.
But if you are working with for example some custom nodes or classes, then assigning a type to a variable still allows you to make it null. and this problem still continues. when you then initialize it as null.
(so in a survival game with slot you could for example have `var currently_active_slot : Slot = null`, but since that active slot only changes on user interaction, it would probably never show up in the inspector)

The last bit of information is that the inspector refreshes whenever you save the file. So that means that if you want to manually update the fields to be the correct one, then saving the file again will do the trick.

## Comparison to seemingly related bug #39465 
At first glance this bug seems to be verry simular to #39465 .
But after some investigation it seems that this is not the same, Thats because there are some differences between the two:
1. This bug only appears in the inspector panel, but not when you place debugger points and go in the debug panel.
2. This bug only appears when the asignments are done after an user interaction.
3. For this bug size does not matter (it even happens for ints and booleans )
4. For this bug its possible to not only get a wrong display of null, but basicly any type (since thats where the bug is 
probably)

### Steps to reproduce

So most of it is already explained in the description, but here is a brief sumary and a little code snippet:

1. To start, create new project, make a scene so you can start the program. 
2. Attach a script to this scene and make sure you keep the _process function
3. add this input condition (which is pressing enter)
4. try different variable assignment

This is for example the situation in the screenshots
```
var control_value = "origional"
var situation1 = null
var situation2 = "i am not null"

func _process(delta):
	if Input.is_action_just_pressed("ui_accept"):
		control_value = "changed" 
		situation1 = "i am not null"
		situation2 = null 
```

But you can ofcoarse change all the assignments

```
var random_preload = preload("res://icon.svg")

var control_value = "origional"
# int <- float
var situation1 = 1
# int <-> string
var situation2_1 = "i am a string"
var situation2_2 = 1234
# null <-> string
var situation3_1 = null
var situation3_2 = "i am not null"
# null <-> object
var situation4_1 : CompressedTexture2D= null
var situation4_2 : CompressedTexture2D= random_preload

func _process(delta):
	if Input.is_action_just_pressed("ui_accept"):
		control_value = "changed" 
		situation1 = 2.42
		situation2_1 = 1234
		situation2_2 = "i am a string" 
		situation3_1 = "i am not null"
		situation3_2 = null
		situation4_1 = random_preload
		situation4_2 = null 
```


### Minimal reproduction project (MRP)

[minimal reproduction project.zip](https://github.com/godotengine/godot/files/14997131/minimal.reproduction.project.zip)