id(web): prosemirror_to_markdown emits inline code containing backticks with a single-backtick fence — save corrupts the code span #879

Bug

In pkgs/id/src/web/markdown.rs, create_marked_text converts a ProseMirror text node with a code mark into a comrak NodeCode with a hardcoded fence length:

// markdown.rs:829-834 (main 45c817e0)
return arena.alloc(AstNode::from(NodeValue::Code(comrak::nodes::NodeCode {
    num_backticks: 1,
    literal: text.to_owned(),
})));

When the code text itself contains a backtick, the single-backtick fence comrak emits is terminated early by the backtick inside the literal, so the saved markdown no longer means what the editor showed.

Verified repro (this run, main 45c817e)

Temporary probe tests run with cargo test --features web --lib web::markdown:: (probes removed after the run; the assertions below are the acceptance tests):

1. markdown_to_prosemirror("Use ``ab`` here")is correct:{"type":"doc","content":[{"type":"paragraph","content":[{"type":"text","text":"Use "},{"type":"text","text":"a`b","marks":[{"type":"code"}]},{"type":"text","text":" here"}]}]}`
2. prosemirror_to_markdown of that document emits: Use `a`b` here — a single-backtick span whose content ends at the inner backtick.
3. Re-parsing the emitted markdown gives a different document: code span a, plain text b, then a stray unmatched backtick in here:
   ...{"text":"a","marks":[{"type":"code"}]},{"text":"b"},{"text":" here"}...`

So one save/load round trip silently corrupts inline code containing a backtick: part of the code becomes plain text and a literal backtick leaks into the prose. The same applies to code text that starts or ends with a backtick (e.g. ` alone, or `a``), where CommonMark also requires padding spaces inside the fence.

Why it matters

This is the save path for the id web editor: any note/document whose inline code mentions a backtick (shell snippets, markdown documentation, template literals) is mangled on save with no error. Same round-trip codec family as #872/#873, but a distinct node type (code mark, not image).

Suggested fix

In the code branch of create_marked_text, choose the fence from the literal:

• num_backticks = (longest run of backticks in the text) + 1.
• If the literal starts or ends with a backtick, pad the literal with a space on both ends (the CommonMark convention comrak itself uses when parsing a ), and make sure the parse direction strips exactly that padding — verify what comrak's parser already does with padded code spans before adding manual handling.

Acceptance criteria

• Round-trip test: ``ab`` (and variants: text that is only a backtick, text starting/ending with a backtick, text containing a double-backtick run) survivesmarkdown_to_prosemirror` → `prosemirror_to_markdown` → `markdown_to_prosemirror` unchanged.
• Existing web::markdown tests still pass (cargo test --features web --lib web::markdown::).
• Coordination: PR fix(id-web): img attribute codec — sequential parse, escaped emission (#872, #873) #878 (for id(web): parse_img_tag substring search lets data-src/data-width shadow the real img attributes — save rewrites the image URL #872/id(web): prosemirror_to_markdown emits img src/alt/title unescaped — quotes truncate values and can inject attributes on reparse #873) is in flight in the same file — sequence or rebase so the img-codec and code-mark fixes do not conflict.