This refactoring PR moves the package-format-agnostic extraction logic (glob matching, hard-link two-pass handling, parent-directory permission preservation) out of deb and into a new tarball package, leaving deb with only the deb-specific DataReader (the ar + data.tar.* opener).

This is a pure, behavior-preserving refactor, no logic was altered — only relocated. It prepares the ground for adding an XZ-strict data reader to enable bin package extraction.

 This PR is the first step to support the `bin` package kind in Chisel.

It introduces the `Store` concept and reworks the package naming model so that `Package.Name` is always a **unique** identifier across the release, while the new `Package.RealName` field preserves the bare name of the package needed for package lookups.

It adds support for:
- a `stores` section in `chisel.yaml`
- `store` and `default-track` fields in  slice definition files. 

The fetching and extraction of the corresponding bins will be implemented in a following PR.

Since Snapcraft 8.12, track and arch are repeated on each line of `snapcraft status` when piping the output.
See canonical/snapcraft#5720

This fix get the right field from the awk parsing.

This is a CI security enhancement.

In #284, we improved the security of the build CI workflow, ensuring the whole CI job wouldn't have unnecessary write permissions to the repository, instead shifting towards a fine grained personal token that would only be used within a single, conditional step that only ran on GitHub release events.

NEW: this PR goes one step further by removing the need to have a bot account (which owns the aforementioned fine grained personal token) with write permissions in the repository's collaborators list. Instead, this PR splits the privileged step into a separate privileged job. This means the new job can use the ephemeral GITHUB_TOKEN to perform the privileged step, without giving unnecessary privileges to other jobs&steps of the workflow.

Closes: #308

- [x] Have you signed the [CLA](http://www.ubuntu.com/legal/contributors/)?

-----

Attempted fix for #305.

Resolve digests through a small preference list (strongest first: `SHA512`, then `SHA256`) instead of hardcoding one field, and carry the hash kind alongside the digest so downloads are verified and cached with the matching algorithm. This covers:

- the Release index table (`Packages` digest),
- the per-package digest (the `.deb`), and
- the `Acquire-By-Hash` path merged from main, which now builds `by-hash/<algo>/<digest>` URLs from the resolved field rather than assuming `by-hash/SHA256/`.

Archives only guarantee a by-hash directory for the *strongest* hash they advertise, so the by-hash URL must be built from that one -- thanks @FinnRG for catching this. Since the preference list is strongest-first, the resolved field is already the right one, and a single ordering serves both purposes.

As of this writing Stonking publishes SHA512 only, in the base suite and in `-security`/`-updates` alike, so the whole suite resolves via SHA512. Resolute and earlier remain SHA256-only

An archive advertising *both* digests, content is now verified and cached under its SHA512 digest rather than its SHA256 one. Cache entries written by an older chisel are keyed by SHA256, so they go cold and are fetched once more, then expire normally (which, at the moment means they don't expire #261, but that's a separate issue). Nothing gets corrupted. Importantly, at present no archive Chisel targets advertises both digests (Resolute is `SHA256`-only, Stonking is `SHA512`-only), so in practice this is not a behaviour change.

### Testing

Added unit tests for the new behaviour and tested manually against the Stonking archive. The by-hash tests cover the four archive shapes: a by-hash directory for the strongest hash only, directories for several hashes (as Stonking actually publishes), a directory for a weaker hash only (a buggy archive, falls back to the named path), and no by-hash directories at all.

### Out of scope

Something i've deliberately decided is out of scope but really **should be fixed** in a followup: The manifest's per-package digest still reads `SHA256`, so on a SHA512-only archive it still errors. Most `chisel cut`'s still work unless the user requests the manifest to be cut too.

Introduce a manifestutil.PackageInfo interface to keep a clear separation of concerns: the manifest is built from whatever a package source reports, not from archive-specific data. As a result, manifestutil no longer depends on archive; archive.PackageInfo keeps its apt-native fields and gains Pkg-prefixed accessors to satisfy the interface. validatePackage now rejects non-SHA256 digests, with a TODO marking recording store digests as future work. This prepares fetching and recording of store bins without changing current behavior.