Standardize bundle assets and refresh shipped implementations

[skylartaylor]

This updates the v0.1 ZIP proposal based on what Sheaf and PluralSpace now ship. It also incorporates the corrections from #12 and keeps SiteRelEnby's wording where it still matches the current source.

This PR proposes:

• New exports should use .pluralport.zip. Existing .openplural.zip files will continue to work, and importers may also accept .openplural.
• The filename is the only part changing. Both ZIP names contain the same v0.1 format: the main file is still openplural.json, the version is still openplural_version: "0.1", and the optional marker file is still openplural-version-0.1.
• Files such as images belong in assets/, and Asset.bundle_path points to each file. For compatibility, importers should also understand Sheaf's current extensions.sheaf.bundle_path. Older exports may point to files under media/; importers can follow those paths, but should not automatically import everything in that folder.
• Importers should rely on openplural.json for the export data. A ZIP may also include a README or an app-specific manifest, but v0.1 does not define a shared manifest format or a way to encrypt the ZIP.
• Importers must safely handle malformed or malicious ZIPs, set reasonable size limits, and tell the user when a file is missing or cannot be imported. When an export includes a file's expected size or hash, importers should check it.

There are two smaller clarifications as well. capabilities.modules can help an importer preview a file, but it should not cause data that is actually present to be ignored. If a relationship refers to a missing relationship type, the importer should keep the relationship and report the problem instead of inventing a type.

I checked the current Sheaf and Ampersand source, the current PluralPort converters, the PluralSpace export from 2026-07-05, and PluralSpace's public import screen on 2026-08-12. PluralSpace's server-side import mapping and full round-trip behavior are still unverified, and the docs say so.

Source versions checked: Sheaf 96c17ef1e36b6be70f8f683ebde78cf06ced75fc, Ampersand 38101d87e500dd21905f4deb2496f1b1b0ca9a48, and PluralPort 7df6357b7f4ee027e50431cf67540ff5715f4a41.

This only changes the preferred filename; it does not change the v0.1 data inside the ZIP. The rest of the OpenPlural to PluralPort rename will stay in a separate PR so this change is easier to review.

@SiteRelEnby, Sheaf appears to recognize ZIP files by their contents rather than their names, and its file picker accepts .zip. Could you check whether any other Sheaf client or deployment would have trouble with .pluralport.zip, and whether the Asset.bundle_path and relationship wording match the current implementation?

@pluralspaceapp, could you confirm that PluralSpace will accept a ZIP named .pluralport.zip, and that the description of its current import/export behavior is fair? (I originally tagged the wrong account here; sorry about that.)

If this covers everything from #12, we can close #12 in favor of this PR.

Closes #9.

[skylartaylor]

@SiteRelEnby @pluralspaceapp I refreshed and consolidated the OpenPlural bundle proposal using the current Sheaf implementation, the available PluralSpace export, and the shipped PluralSpace import UI. GitHub does not allow formal review requests for non-collaborators, so I am tagging you here instead. The PR body has focused implementation questions for each of you; Sheaf PR #12 is incorporated with its maintainer-authored wording preserved where possible. (edited to correct an earlier ping to the wrong account - sorry about that.)

[skylartaylor]

I think it's worth going ahead with .pluralport.zip as the preferred extension to reduce confusion around the rename, so I've updated the PR to reflect that. .openplural.zip will remain supported for compatibility, and the v0.1 identifiers inside the bundle are unchanged. I'll keep the rest of the rebrand in a separate PR to make this easier to review.

[SiteRelEnby]

#17 has some changes worth merging, lmk if you want to do the honors or us, you got your PR in first so your call and I think we each caught some stuff the other missed.

a

[SiteRelEnby]

as for .pluralport.[zip|json]: The explicit preferred case in 1.5.0+ and works fine with a backward compatibility case for openplural.zip with openplural.json inside. For <1.5.0, only openplural.json is recognized as valid inside the zip, and if you tried renaming pluralport.json -> openplural.json then it would not work unless also changing inside the file back to openplural_version too. In either version the zip itself can have any filename, yeah, purely content-based detection.