fix: update_page properties now update in-place via upsertBlockProperty

[nlsn]

Closes #48

Problem

update_page called with a properties dict and no content was routing
through _set_page_level_properties → logseq.Editor.setPageProperties.
In practice, setPageProperties appended a new block to the page body with
properties serialized as text, rather than updating the existing page-level
property lines in place. The appended block was invisible to Logseq's property
system and the success message was misleading.

Secondary bug: tag values were serialized as Python list repr (['mcp-test'])
instead of Logseq syntax ([[mcp-test]]).

Fix

In src/mcp_logseq/logseq.py, update_page_with_blocks: replaced the
_set_page_level_properties call (and the pre-fetch via
_get_page_level_properties) with a single call to _update_page_properties.

That method calls logseq.Editor.upsertBlockProperty once per key on the
first block (the page-properties pre-block), updating values in place and
implicitly preserving untouched keys.

The tags serialization bug is also resolved — upsertBlockProperty receives a
proper Python list and Logseq renders it correctly as [[tag]] references.

Tests Added

• test_update_page_properties_only_updates_in_place — regression test;
  asserts no setPageProperties/appendBlockInPage call, and exactly N
  upsertBlockProperty calls targeting the first block
• Updated test_update_page_append_mode_merges_properties and
  test_update_page_replace_mode_replaces_properties to match new API call
  sequence and result shape

[nlsn]

Hi @ergut - before merging, I want to flag a potential secondary issue I haven't had time to investigate yet.

The fix routes tag values through upsertBlockProperty with a Python list, which Logseq renders as [[wikilink]]-style page references. This may be the correct behavior, but I want to verify it's consistent with what create_page produces for tags, and that it matches user expectations — plain tags and page references behave differently in Logseq (backlinks, page creation, etc.).

Could you hold off on merging until I've had a chance to test this? Thanks for your patience.

[ergut]

Thanks for the PR, the careful repro in #48, and for flagging the tags wikilink concern yourself and asking to hold off. Good instinct: my review reached the same area and found some blocking issues, so here is the full picture.

1. DB mode regression (blocking): _update_page_properties uses upsertBlockProperty unconditionally. That is exactly the approach 5b99215 moved away from: block level properties don't register as page level on DB graphs (invisible to (page-property ...) queries and the page info panel). The PR has no db_mode guard.

2. Replace mode no longer replaces: both modes collapse to the same per key upsert, so properties the caller didn't supply survive a mode: replace update. The updated test only asserts on the returned dict, not page state, so this doesn't show up at test level.

3. Append mode merge semantics are lost: the previous code returned the full merged property set; the PR returns only the caller supplied keys, and the assertion that verified existing key preservation was removed.

4. The repr claim doesn't hold: the tags:: ['mcp-test'] bug originates in parser.py (BlockNode.to_batch_format()), not in the property write path. Both setPageProperties and upsertBlockProperty receive values via JSON and serialize them correctly. That bug is fixed in fix: prevent Python repr in block property serialization #53. Your wikilink concern is real though, and it's a third reason tag semantics shouldn't be decided in the property write layer.

A version I'd be glad to merge: gate on graph type. File mode uses upsertBlockProperty on the first block, which is the native file mode representation of page properties, so it stays correct even after upstream fixes setPageProperties. DB mode keeps setPageProperties. Preserve the append and replace semantics, and add tests asserting actual page state for both modes. The db_mode flag currently lives in tools.py and would need plumbing into logseq.py. The upstream behavior itself is tracked in #51.

Happy to help if you want to take this, otherwise I can pick it up and credit your repro.

[ergut]

Thanks again for the careful repro in #48 and for flagging the wikilink concern. I went ahead and implemented the graph-type-aware version we discussed so this doesn't stall, and credited you as co-author on the commit.

It gates the property write on graph type: DB graphs keep setPageProperties, file graphs use upsertBlockProperty on the first block (the native file-graph representation, so it stays correct even after the upstream setPageProperties issue in #51 is fixed). Append and replace semantics are preserved in both modes, with tests asserting the actual API call sequence per mode and graph type.

Opened it as #62. Happy to fold in any further thoughts you have on the tag semantics.