`[Bug] Local API: Markdown Serialization is "Mention-Blind" and causes formatting shifts on UTF-8 characters`

Have you read a contributing guide?

• I have read CONTRIBUTING.md
• I have searched the existing issues and didn't find any that were similar
• I have considered creating a pull request with fixes instead of a bug report and want to proceed

Current Behavior

The Local API (v1) markdown serialization/deserialization layer is currently lossy and destructive for native AnyType features. Through 18+ different trial-and-error experiments with markdown/HTML syntax, we have confirmed that it is impossible to create or preserve a native "Avatar Relation" (Mention) via the API's markdown body.

1. Mention-Blindness (Lossy Export/Import):

• When an object containing a native Relation Mention is exported via GET ...?format=md, it is returned as a naked markdown link: [Name](anytype://object?...). Crucial metadata (the "Mention" flag and Avatar icon) is stripped.
• When sending markdown back via PATCH or POST, any attempt to trigger a native mention (using [@Name], [[ID]], <@ID>, or even HTML span tags with data-attributes) fails. Every variation is rendered as a standard blue underlined web link, losing the native Relation UI.

2. Formatting Offset Shifts on UTF-8:

• When a text block contains multi-byte characters (e.g., Turkish ğ, ş, ı, ö), inline formatting tags (**, *) physically shift to the right during a PATCH operation.
• Example: **Görsel:** often becomes G**örsel:** or similar corrupted offsets after a round-trip, rendering the markdown layer unusable for automated text processing in non-English languages.

Expected Behavior

• The Markdown parser should recognize a specific syntax (e.g., [@Name](anytype://...)) to regenerate native Mentions during a PATCH.
• Formatting offsets should be calculated based on character length/UTF-8 boundaries rather than raw byte offsets.
• Priority Request: Expose format=blocks (JSON block array) to allow safe, non-lossy manipulation of object content without relying on the flawed markdown parser.

Steps To Reproduce

1. Create a native mention in AnyType.
2. Fetch markdown via API: Observe the stripped link.
3. Patch the same markdown back: Observe the permanent downgrade to a standard link.
4. Patch formatted text with Turkish characters: Observe the corrupted bold/italic positions.

Environment

- OS: Windows 10 
- Version: 0.54.9

Anything else?

This "mention-blindness" effectively makes it impossible to build automation scripts for cross-linking objects (e.g., automatically mentioning characters in book chapters) while maintaining AnyType's premium UI look and feel.

Start at the Local API (v1) markdown serialization/deserialization layer and reproduce the mention round trip and UTF-8 formatting-offset behavior described in the issue. Done would require preserving native mentions, keeping formatting positions correct for multi-byte characters, and determining whether a non-lossy blocks representation can be exposed.