Specifying manifests vs documents

Copy/pasting from @LiaHiscock's comments in https://github.com/WICG/install-element/pull/4#discussion_r2561692967:

"""
Off the top of my head, there are a couple complications with requiring only a manifest file. The main one brought up was that manifests can be served over different domains via CDN, which opens the door for spoofing issues, and would require additional validation, likely something like -

1. Load the manifest file in the background.
2. Parse the start_url, and load that in the background.
3. Verify that the document at start_url contains a link back to same manifest from step 1.

This extra loading could be avoided but would exclude manifests served via CDN, as noted by Dan in his recent reply -

One thought for manifest_url only install - This seems maybe OK if we require the manifest is same-origin as the start_url. Most manifests we see satisfy this. I could see this simplifying the cross-origin install, although the tradeoff is potentially stale manifest urls.

We're definitely open to iterating on the attribute design, especially given that a direct manifesturl link would enable custom rendering in the button, but given that our mutually established goal was to OT/ship a basic element to start getting developer feedback, we thought proposing a 1:1 matching of declarative attributes to API parameters would make the most sense. This will also give us more time to discuss design, usability tradeoffs, and technical implementation with Dan and co, without holding up the initial declarative OT.
"""

Start with the issue text and the linked pull request discussion, then review the referenced manifest, CDN, same-origin, and start_url concerns. The payload names no files, tests, or entry points. Done would require an agreed design for specifying manifests versus documents, but no concrete acceptance criteria are provided.