Task: Publish both ORE engine versions during provisioning

Make both engine versions available to the compute grid. The seed registers both app versions with their platform packages, and provisioning uploads both tarballs. Then submit a job on each version to prove the choice works.

• compute_ore_app_seed.sql registers the ORE app with both engine versions and their platform packages.
• The ACME provisioning recipe publishes both engine packages, and the tangled .ores script matches it.
• A grid job runs on v1.8.16.0 and another runs on v1.8.17.0.

• Add a second app-version block to compute_ore_app_seed.sql for 1.8.17.0, with the package URI and the sha256 the v17 tarball actually has. Leave the 1.8.16.0 block alone so both versions stay seeded. The file is hand-maintained, not generated.
• Add a second compute publish-package line to the ACME provisioning recipe, then regenerate the tangled .ores from it. The .ores file carries a "do not edit by hand" header, so compass build --direct tangle_shell_scripts owns it.
• Change nothing in CMake. vendor_compute_packages globs every *-x64-linux.tar.gz in external/ore/packages/, so the v17 tarball is vendored as soon as it lands in that directory.
• Verify by provisioning a fresh database from the recipe and running one grid job per engine version. compute publish-package upserts by app name and merges platforms, so the second call adds a version rather than replacing the first.

• The seed block is a copy of the 1.8.16.0 block with the version, the package URI, and the sha256 substituted. The sha256 is the v17 value recorded in external/ore/packages/manifest.json.
• package_ore.sh already tells the packager to update this seed file when a package replaces the seeded version. This task adds a version instead of replacing one, so both blocks stay.
• The v17 version string is the provisional tag on the engine fork. When upstream tags 1.8.17.0 properly, the tarball is rebuilt, and the sha256 here and in the manifest change with it.
• The storage key is built from the app-name argument, not from the file name. compute_storage::package_key concatenates packages/{app_name}/{version}/{app_name}-{version}-{platform_code} and the publisher's ext default is .tar.gz, so publish-package ORE 1.8.17.0 x64-linux --file .../ore-1.8.17.0-x64-linux.tar.gz uploads to packages/ORE/1.8.17.0/ORE-1.8.17.0-x64-linux.tar.gz. That is byte-for-byte the package_uri in the seed, so the lowercase file name and the uppercase key do not conflict. Checked in projects/ores.compute/api/.../compute_storage.hpp and package_publisher.hpp.
• The seed was run against the live database inside a transaction that was then rolled back. It reported INSERT 0 0 for the ORE app and for the 1.8.16.0 block, and INSERT 0 1 for the 1.8.17.0 block, so both idempotence guards hold and the new block inserts exactly one platform row. The rollback left the database untouched.
• compass sql runs as postgres by default, and that account is not a valid modified_by for the compute tables: the insert triggers reject it with "Invalid modified_by: postgres". Pass -u ddl to check these tables by hand.

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Abandoned at sprint 25 close, as part of the reset to one approach for sprint 26. The work is not in the sprint 26 plan. The done tasks stay as the record of what shipped.