feat: hybrid single-file reports for heavy attachments

[grootstebozewolf]

Summary

Addresses allure-framework/allure3#88: single-file reports with heavy attachments become slow / hard to open once the HTML grows into the 50–100MB range.

Approach (hybrid single-file)

• Per-attachment “heavy” threshold: raw size ≥ 1 MiB (HEAVY_ATTACHMENT_BYTES)
• Light attachments stay embedded in index.html (portable single-file UX)
• Heavy attachments are written as sibling files under data/attachments/ instead of base64 in the HTML
• Runtime: if a key is missing from window.allureReportData, fall back to a relative fetch (existing multi-file path)
• CLI warnings when generated single-file HTML is ≥ 50 MiB (soft) / 100 MiB (severe)
• Console warn when any heavy attachments were externalized (recommend allure open / HTTP over file://)

Security

• Sanitize untrusted attachment contentType before building data: URLs
• Reject absolute / scheme-based report data paths (no open-redirect style fetch targets)
• External writes reuse existing report ReportFiles confinement

Scope

• Awesome plugin first (Classic / Allure2 parity left for follow-up)
• Shared helpers in @allurereport/core-api (formatByteSize, thresholds, warn helper)
• results pack reuses formatByteSize

Test plan

• yarn workspace @allurereport/core-api test test/utils/size.test.ts (9 passed)
• yarn workspace @allurereport/web-commons test test/data.test.ts (12 passed)
• yarn workspace @allurereport/plugin-awesome test (45 passed, 1 pre-existing todo)
• CI green on this PR
• Manual: generate Awesome --single-file with a multi-MB attachment; confirm index.html does not embed it and sibling file loads via allure open

Feedback wanted

• Are 1 MiB / 50 MiB / 100 MiB the right defaults?
• Is hybrid (external heavy attachments) acceptable as the default for singleFile: true, or should pure inline remain default with an opt-in?
• Should Classic / Allure2 land in the same PR or a follow-up?

Closes #88