Publish a key-stripped zip for Chrome Web Store uploads

The Web Store dashboard rejects any manifest containing a "key" field
("key field is not allowed in manifest"), but extension/manifest.json
pins one so unpacked/dev installs get a stable ID. Add a third release
asset with key stripped from a copy, so future releases have an
upload-ready zip without touching the pinned manifest.

.github/workflows/release.yml

@@ -18,11 +18,34 @@ jobs:
       - name: Package extension
         # Chrome requires manifest.json at the zip root, both for Web Store
         # upload and for manually loading unpacked -- so this one archives
-        # only extension/'s contents, not the whole repo.
+        # only extension/'s contents, not the whole repo. Keeps the pinned
+        # "key" field, so unpacked loads get the stable, predictable ID.
         run: |
           cd extension
           zip -r "../kget-capture-extension-${GITHUB_REF_NAME}.zip" .
 
+      - name: Package extension for Web Store upload
+        # The Chrome Web Store dashboard rejects any manifest containing a
+        # "key" field ("key field is not allowed in manifest") -- it assigns
+        # its own permanent ID on first publish instead. Strip it from a
+        # copy so this zip is upload-ready; the other extension zip above
+        # keeps "key" for stable unpacked/dev IDs.
+        run: |
+          rm -rf /tmp/store-extension
+          cp -r extension /tmp/store-extension
+          python3 -c "
+          import json
+          path = '/tmp/store-extension/manifest.json'
+          with open(path) as f:
+              manifest = json.load(f)
+          manifest.pop('key', None)
+          with open(path, 'w') as f:
+              json.dump(manifest, f, indent=2)
+              f.write('\n')
+          "
+          cd /tmp/store-extension
+          zip -r "$OLDPWD/kget-capture-store-${GITHUB_REF_NAME}.zip" .
+
       - name: Package source
         # Separately, the native-host installer bundle (install.sh,
         # native-host/, keys/) needs the whole repo. git archive only
@@ -36,4 +59,5 @@ jobs:
           files: |
             kget-capture-${{ github.ref_name }}.zip
             kget-capture-extension-${{ github.ref_name }}.zip
+            kget-capture-store-${{ github.ref_name }}.zip
           generate_release_notes: true

README.md

@@ -115,7 +115,19 @@ Store listing); that step can't be scripted.
 
 Prebuilt releases are published on the
 [Releases page](https://github.com/andwati/kget-capture/releases); each
-`vX.Y.Z` tag push builds and publishes one automatically.
+`vX.Y.Z` tag push builds and publishes one automatically, as three zips:
+
+- `kget-capture-vX.Y.Z.zip`: full source, for `install.sh`/`install-remote.sh`.
+- `kget-capture-extension-vX.Y.Z.zip`: just the extension, manifest at the
+  zip root, `key` field intact, for manual "Load unpacked" installs.
+- `kget-capture-store-vX.Y.Z.zip`: same extension, but with `key` stripped,
+  for uploading to the Chrome Web Store dashboard. The Store rejects any
+  manifest containing `key` ("key field is not allowed in manifest") since
+  it assigns its own permanent ID on first publish, which won't match the
+  pinned ID (`keys/extension-id.txt`) the other zips use. After the first
+  successful Store publish, update `native-host/com.kget_capture.host.json`'s
+  `allowed_origins` to include the Store-assigned ID alongside the pinned
+  one, so both installs can reach the native host.
 
 ## Known limitations