fix(embed): remove the 50 MB host-fetch cap

[bendersej]

Background

@simplepdf/embed fetches a url document from the host page and hands it to the editor as a base64 data URL inside a JSON-string postMessage, with a 50 MB cap. Above the cap the editor loads the url itself (?open), which cannot reach a document behind the page's login. The cap was meant to go so the editor owns any size ceiling, but review showed it is the only guard on that transport: in Chromium the host tab crashes from 192 MiB when the data URL is JSON-stringified, and FileReader returns an empty result from ~384 MiB. This draft holds the cap removal until LOAD_DOCUMENT accepts a Blob, which removes those limits.

Changes

• Removes the 50 MB host-fetch cap (DOCUMENT_SIZE_CAP_BYTES, readStreamCapped)
• Falls back to ?open when the browser cannot encode a url document as a data URL, and logs load_document_failed when a non-url document cannot be encoded
• Extracts a probe-only readiness helper in the mount tests; a test pins that a url document declared over 50 MB is posted to the editor, not sent to ?open
• README lists the fallback triggers
• Changeset (patch: embed, react, web)
• Sends every document as a Blob (LOAD_DOCUMENT object message) once the editor accepts it
• Deletes the FileReader data-URL step

Notes

• Do not merge as is: without a binary transport, a url document of 192 MiB or more crashes the customer's tab in Chromium (measured: 191 MiB ok, 192 MiB crash, at the JSON.stringify of the data URL). This draft becomes the SDK half once LOAD_DOCUMENT accepts a Blob.
• Not written yet (they change with the binary path): a test for the streamed half of the removed cap, and one for the encode-failure fallback.
• The changeset is rewritten with the binary send path.