Changing a property's type away from Text leaves its closed values behind, invisible but still enforced

Summary

When a property that has closed values is changed to type Node, the
closed values are not removed. They also stop being visible anywhere in the UI,
because Logseq does not render a closed-value list for Node properties.

The result is a property that looks correctly configured in every screen the UI
offers, but still carries a stale enum in the database. That enum is still
enforced by validate-db's fix-non-closed-values! pass, which deletes any
value not in it — and since a Node property's values are node references while
the orphaned enum holds text choices, every value of that property is
eligible for deletion.

This issue is about the orphaned state itself. The deletion behaviour is filed
separately as a companion issue, because the two are independently fixable: a
graph that already contains an orphaned enum stays dangerous even if the
deletion pass is corrected, and correcting the type-change path does nothing for
graphs already in this state.

Version

Logseq DB version, desktop macOS arm64 (build 2287).
db-worker-node build-time 2026-07-28T15:15:45Z, revision 9a11243-dirty.

Steps to reproduce

1. Create a property with type Text and give it two closed values
   (e.g. raster, vector).
2. Change the property's type to Node.
3. Open the property's configuration and look for the closed values.

Expected: either the closed values were removed as part of the type change,
or they are shown somewhere so the user knows they still exist — or the type
change is refused while closed values exist, the way a many→one cardinality
change is already refused when data would be lost.

Actual: the closed values are still in the database, reachable via
:block/_closed-value-property, but appear in no UI surface. There is no way to
discover or delete them from within the app.

Evidence from a real graph

In the graph where this was found, the affected property was the only one of
eleven closed-value properties whose logseq.property/type was node; the
other ten were all default.

Creation timestamps show the ordering: the property was created at
1783816803975 and its first closed value at 1783816803982 — seven
milliseconds later, i.e. created together as a Text property with an enum. The
second closed value followed about three days on. Both long predate the type
being node.

There is no UI path to add closed values to a Node property, so they cannot have
been added after the change. The only consistent reading is that the property
was retyped and the closed values were left behind.

Why it matters

The invisibility is the harmful part. A user inspecting the property sees a
correctly configured Node property. Nothing indicates that a stale enum exists,
that it is still being enforced, or that running "Validate graph" will delete
data because of it.

Verified fix in that graph: deleting the two orphaned closed-value entities
directly made the property behave correctly, because fix-non-closed-values!
selects on :block/_closed-value-property and skips properties with none. That
repair required going outside the app.

Suggested fixes

1. Remove closed values when a property's type changes to one that does not
   support them.
2. Or refuse the type change while closed values exist, with a message,
   matching the existing precedent for many→one cardinality changes.
3. Failing either, surface orphaned closed values in the property
   configuration UI so they can be seen and removed.

Related

Companion issue: logseq/db-test#1068 — validate-db's fix passes silently delete user data
(no notification, :debug-only logging, no :block/updated-at bump, no UI
refresh). That issue is what turned this configuration inconsistency into
actual lost work.