Add inline <adf> tag support

[merphx]

Summary

Extends the existing <adf> passthrough feature to support inline placement — inside paragraphs, table cells, headings, and anywhere else marked processes inline content. Previously, <adf> tags only worked when surrounded by blank lines (block-level).

I've done some real-world testing of this, and it's working quite well. I've also done a few static analysis passes with a coding agent, and I think all the use cases are covered.

Changes

Inline <adf> tag support

• <adf>…</adf> can now appear within any content, embedding the ADF node(s) into the surrounding paragraph / list item / table cell / etc. content array
• Delegates to the block-level parseAdfTag under the hood:
  • Supports both single-object and JSON array forms, consistent with block-level behaviour
  • Error handling is identical to block-level: throws on invalid JSON, missing type, empty tag, non-object array
    items
  • No validation is performed on whether the embedded node type is contextually valid in ADF (inline vs block). This is consistent with block-level behaviour and the library's passthrough philosophy.
    • This is especially important for table cells where Confluence supports block-level content whereas Markdown table cells do not.
• Placing an <adf> tag inside a Markdown link (e.g. [text <adf>...</adf>](https://example.com)) is not supported because it's not valid ADF (link is a mark, not a node, so it can't act as a container for other ADF nodes). I wasn't really sure how the library should handle this, so I just threw my hands up and declared it unsupported 😅

Reviewer notes

• The inline extension uses marked's level: 'inline' extension API to intercept <adf>…</adf> as a single token before marked's default inline lexer can split it into fragments. This is the only reliable approach — post-processing fragmented tokens would be brittle.

• The extension is registered on a private new Marked() instance rather than via marked.use() on the global singleton. marked.use() was the natural first approach for adding an extension, but it has a global side-effect: importing marklassian would silently register the extension in the consumer app which might not be desirable. A private instance avoids this entirely.

• When content appears by itself on a line without any formatting markers, marked automatically treats that as a paragraph node. This results in a subtle difference between how markdownToAdf() handles block-level <adf> nodes and inline <adf> nodes that appear by themselves. I think the behaviour as implemented is correct, but it may be a little bit unintuitive, so I've added a unit test explicitly documenting it (lib/test/adf-passthrough.test.ts:420):

  • Block level (i.e. <adf>\n{...}\n</adf>) is added verbatim to the document.
  • Inline without any other block-level markers (i.e. <adf>{...}</adf>) is stuffed into a paragraph node (due to how marked works).
  • Inline with block-level markers (e.g. # <adf>{...}</adf>) does what you'd expect (e.g. puts the ADF inside a heading node).

  Compare this with how regular text is handled, and it might also make more sense (e.g. Kia ora te ao! gets parsed as a paragraph vs # Kia ora te ao! is parsed as a heading — exactly the same behaviour if we replace the text with an inline <adf> node).