portal: page-relative images (./img.png) in the Markdown copies and llms-full.txt point to an address that 404s #446

Summary

Since #437 (fumadocs-core 16.17, fix for fuma-nama/fumadocs#3662), the Markdown copies and llms-full.txt keep images as authored instead of <img src="__img0" />. This works for images in src/static (/images/x.png), but page-relative images (an image beside the page, ./x.png) still lead nowhere:

• The image is bundled into the page (inlined as a data URI / hashed asset), so nothing is published at <page-dir>/x.png → 404.
• In llms-full.txt all pages are concatenated, so ./x.png has no page to resolve against at all.

Not a regression (before #437 these were __img placeholders), but the copies are still broken for this case. The e2e test added in #437 only covers /images/... from src/static.

Steps to reproduce

1. In src/content/img-tests/, add beside.png and a page md-page.md:

   ![Beside the page](./beside.png)

   (same for an .mdx page, also inside <Tabs> / <Steps>)
2. apimatic portal generate with dev at 1bd40e5.
3. Open /img-tests/md-page.md and /llms-full.txt, then request the image address they contain.

Actual

The HTML page itself renders the image correctly.

Expected

Page-relative images in the Markdown copies and llms-full.txt point to an address that resolves, e.g. the published asset URL (/assets/beside-<hash>.png) or an absolute URL when portal.site.url is set.

Notes

• Fumadocs 16.17 slices the copy from the authored source, so it keeps the address but doesn't make it resolvable; a replaceSource() plugin (fumadocs-core/mdx-plugins/stringifier) could rewrite it, the same approach noted for prefixing root-relative links under a base path (.ai/plans/portal-subpath-hosting.md, section 9).
• Related known limitation: root-relative images in the copies don't carry the base path when hosted under a subpath.

Environment

• apimatic-cli dev @ 1bd40e5 (fumadocs-core/ui 16.17.1, fumadocs-mdx 15.4.7)
• Windows 11, Node 24.14.0