read: paragraph text that looks like a Markdown block becomes structure on publish

[willkg]

Problem

`read` and `export` write a paragraph's text as Markdown without escaping a leading block marker, so text that looks like a Markdown block turns into that block on the next publish. Found in the second review of #55.

Reproduced 2026-09-25 (read → publish):

storage	read writes	publish sends
` 1. not a list `	`1. not a list`	` not a list `
` # not heading `	`# not heading`	` not heading `
` > 5 errors `	`> 5 errors`	` 5 errors `

The page's content changes silently on a read → update cycle, and the Markdown is a fixed point after the first cycle, so no round-trip test notices. It affects every paragraph `read` writes: top level, layout cells, macro bodies, and (since #55) raw table cells. A GFM pipe-table cell is not affected, because its text is inline.

Notes

• The fix belongs where `storage_to_md.go` renders a block-level `

  ` (`renderBlock`'s `p` case), escaping a leading marker with a backslash (`1\.`, `\#`, `\>`).

• The markers to cover include `-`, `+`, `*`, `1.`/`1)`, `#`, `>`, a line that is only `---`/`===` (a thematic break or a setext underline), four leading spaces (indented code), and `|` if a line could read as a table row. Probably also a leading `<` that would start an HTML block.
• The escape must survive the next read, so the Markdown stays a fixed point.

[willkg]

The table property test in #55 hit this on a real page: a table in a personal space whose cell reads > 90 days (a threshold). The table reads back raw, because a cell carries align="right", and on publish the cell's text becomes <blockquote><p>90 days</p></blockquote>. The table generator in internal/convert/table_property_test.go avoids leading block markers so that it does not fail on this; once this is fixed, that restriction can go.