feat(test-site): add tricky rendering cases for table, diagrams, plugins

[arshinsikka]

What is the purpose of this pull request?

• Documentation update
• Bug fix
• Feature addition or enhancement
• Code maintenance
• DevOps
• Improve developer experience
• Others, please explain:

Overview of changes:

• Adds a new test site under packages/core/test/tricky-site/
• Contains individual .md pages for testing rendering of:
  • <table> elements with/without <tbody>
  • <mermaid> flowchart rendering
  • <puml> plugin rendering (inline, named, and external)
  • Shorthand syntax conversion (<span heading> ➝ <span slot="header" ...>)
  • <tree> plugin rendering directory-like structures
  • Auto-anchor injection into heading elements
• Includes a clean index.md for navigation and a complete _site.json
• Test site is self-contained, buildable, and does not interfere with main docs/tests

Anything you'd like to highlight/discuss:

• Let me know if you'd prefer the site be renamed (e.g. render-corner-cases) or placed under a different path.
• This can be extended in future PRs to include more edge cases.

Testing instructions:

To test the site locally:
npx markbind serve packages/core/test/tricky-site
Navigate to each page and confirm that the rendering reflects expectations.

Proposed commit message: (wrap lines at 72 characters)

feat(test-site): add tricky rendering cases for table, diagrams, plugins

Adds a reusable test site under packages/core/test/tricky-site
to visualize rendering of tricky or previously buggy scenarios.
Includes pages for

, , , shorthand syntax,
tree plugin, and auto-anchors. Helps contributors manually test
and verify rendering behavior when working on plugins or layout.

---

Checklist: ☑️

• Updated the documentation for feature additions and enhancements
• Added tests for bug fixes or features
• Linked all related issues
• No unrelated changes

---

Reviewer checklist:

Indicate the SEMVER impact of the PR:

• Major (when you make incompatible API changes)
• Minor (when you add functionality in a backward compatible manner)
• Patch (when you make backward compatible bug fixes)

At the end of the review, please label the PR with the appropriate label: r.Major, r.Minor, r.Patch.

Breaking change release note preparation (if applicable):
Not applicable

Give a brief explanation note about:

• what was the old feature that was made obsolete
• any replacement feature (if any), and
• how the author should modify his website to migrate from the old feature to the replacement feature (if possible).

[arshinsikka]

Closing this PR in favor of a cleaner version from a fresh branch.