API cannot write values to UI-created properties

Nobody has claimed this yet.

### Search first

- [x] I searched and no similar issues were found

### What Happened?

Properties created through the API are confined to plugin.property./*. Properties created in the UI live under user.property/*, and the API can read them but cannot write values to them.

I'd be perfectly happy with the API being unable to create or alter the schema of UI-owned properties. That's a reasonable sandbox boundary. The problem is that it also can't set values on them, and that's what makes the current design unworkable.

The practical consequence is a split brain. Say I want a last-updated property on my pages. I now need two of them: one that the UI writes to and one that the API writes to. Same display name, two distinct entities, two sets of values, and no query that unifies them. This isn't cosmetic — every page I touch from either side deepens the divergence, so the longer the graph is in use, the worse the inconsistency gets and the less any property can be trusted as a source of truth.

Making this worse: a write to a user.property/* ident doesn't fail. Logseq returns the same response it returns for a successful write. Any client that trusts the API response will believe it has recorded a value it has not recorded. Silent data loss is a much bigger problem than a rejected call.

What I'm asking for:

Allow the API to read and write values on user.property/* properties. Keep definition and schema changes sandboxed if that's the concern — value writes are the thing that actually matters for automation.
Failing that, at minimum make out-of-sandbox property writes return an explicit error rather than a success-shaped response.

As it stands, the usability of properties is overshadowed by the data inconsistency that using them via the API creates. I'd rather the API refuse loudly than quietly build a second, parallel dataset.

### Reproduce the Bug

1. create "Staus" property in user interface.
2. add a status property to a page via API.

### Expected Behavior

existing status property gets used

### Screenshots

_No response_

### Files

_No response_

### Browser, Desktop or Mobile Platform Information

all DB versions

### Additional Context

_No response_

### Are you willing to submit a PR? If you know how to fix the bug.

- [ ] I'm willing to submit a PR (Thank you!)

No files or tests are identified. Start by reproducing an API write to a UI-created property, then trace the API property-write path and its sandbox handling. Done means value writes either update existing user.property/* properties or return an explicit error, with coverage for both behaviors.

Written by the indexing model from the issue text.