feat(azure): make the package workflow say where the artifact went and what to do with it

[cevheri]

Why

The workflow ended with a green tick and no answer to the only question its operator has: where did the package go, and what do I do with it? The image digests it pinned were buried in the build log, the artifact link appeared nowhere in the output, and the Partner Center steps used to live in a document that is no longer in the repo.

What the run now says

Three sections, each written by the step that knows its facts, as soon as it knows them — so a run that fails validation still leaves a usable summary instead of nothing:

1. what was built — package version, app version, both image digests, the zip name and its SHA-256;
2. the arm-ttk result — every failure and warning named, written before the gate so a failing run explains itself in the summary and not only in the log;
3. where it went and what to do by hand — artifact link, a copy-pasteable sha256sum -c line, and the Partner Center sequence.

Rendered output from run 31173195066 (dispatched on this branch):

## Azure Marketplace package 1.0.0

| | |
|---|---|
| Package version | `1.0.0` |
| App version | `0.9.66` |
| App image | `ghcr.io/libredb/libredb-studio@sha256:816d6060…` |
| Caddy image | `docker.io/library/caddy@sha256:5f5c8640…` |
| Package zip | `libredb-studio-azure-1.0.0.zip` |
| Package zip SHA-256 | `a5aaa848c51058d057bea6e9babb41122fec480483d352de51c6c1605efdc4a2` |

### arm-ttk marketplace suite

**35 tests, 0 failed, 1 warned**

- warning - URIs Should Be Properly Constructed: Function '' found within 'applicationUrl'

### Download
…

The builder writes its provenance down

dist/azure/build-metadata.json now lands beside the zip, because none of that provenance is recoverable from the zip itself — it is two JSON files with no trace of which app version or image digests they deploy. It is also what the summary reads, so the workflow does not have to parse the build's stdout.

The checksum is read back off disk rather than computed from the bytes we meant to write, since its entire purpose is to describe the file a human uploads by hand.

One trap worth the paragraph it costs

Verified by downloading the artifact from the previous run: GitHub wraps artifacts in an archive of its own, so the download is a zip containing libredb-studio-azure-1.0.0.zip, whose own root holds the two JSON files. Partner Center needs the inner one — uploading GitHub's wrapper would fail certification on package structure. The summary says so where someone about to make that mistake will read it, and deploy/azure/README.md repeats it.

Verification

• The two bash summary steps were rendered locally by extracting their run: blocks from the workflow file itself, not by retyping them, and executing them against a real build-metadata.json — the same technique fix(ci): let the arm-ttk gate decide the azure package job, not the error stream #309 established after the local check there failed to predict the job.
• Dispatched for real on this branch: run 31173195066 — success, all 10 steps green, both summary steps included, artifact-url populated (.../artifacts/8991777005), so the link in the summary is live.
• New unit test pins the metadata file's shape and checks zipSha256 against an independently computed hash of the zip on disk.
• Six local gates clean, and coverage:check → 100.00% (29254/29254).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud