fix: strip residual macro HTML from Markdown output (#5)

[aqueeb]

Summary

Closes #5 — converted Markdown was still leaving "blocks of HTML surrounded with Markdown" for unhandled Confluence macros (e.g. a Change History macro), forcing a second cleanup tool.

Root cause: unhandled macros are wrapped in <div class="...">. postProcessMarkdown already stripped all closing </div> and all <span> tags and converted a handful of known macro classes — but had no general removal of residual opening <div ...> tags, so unrecognized macro wrappers leaked.

Fix: a residual-HTML cleanup pass (after all specific macro conversions) that removes opening/closing <div> and non-semantic HTML5 sectioning wrappers (section, article, header, footer, nav, aside, figure, figcaption), keeping inner content. Tags the converter intentionally emits (<br>, <details>, <summary>, <img>) and table tags are excluded — so real content and raw-HTML fallback tables are preserved. No content is dropped (the reporter's accepted "convert to text" option).

Before → After (representative macro doc)

<div class="conf-macro output-block">          ->  | Version | Author |
| Version | Author | ...                            |---------|--------|
<div class="plugin_attachments_container">          | 1.0     | Jane   |
Attachments                                         Attachments

Output now contains zero <div>/<span> tags; issue #6's testpage.doc converts identically (no regression).

Testing (TDD, same rigor as #8)

• Strip tests written first and confirmed failing, then fixed.
• Preserve-set locks: <details>/<summary>, <img>, and raw fallback <table> tags survive.
• End-to-end ConvertHTMLToMarkdown on a macro-wrapped document (change-history table + unknown macro + attachments) → clean Markdown.
• Fuzz seeds added to both FuzzPostProcessMarkdown and FuzzPreProcessHTML; active fuzzing 45s each (≈204K + 590K execs) — no crashers.
• go test ./... -race green · go vet clean · gofmt clean on markdown.go/markdown_test.go.

Notes / limitations

• Like the existing span/div cleanup, this pass is not fenced-code-block aware, so a literal <div> inside a ``` code sample is also stripped. Matches current behavior; a code-fence-aware cleanup is a possible follow-up.
• Dropping entire named macro bodies (vs. keeping their text) would need a real HTML parser (regex can't match nested <div> reliably) — out of scope.
• I don't have the reporter's exact export; happy to validate against a real sample. The general wrapper-strip resolves the described symptom.

🤖 Generated with Claude Code

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!