Make supply chain layout configurable (steps, signing keys)

Feature Request

Problem

The in-toto supply chain layout enforced by DevGuard is currently hardcoded to a fixed three-step pipeline:

1. post-commit — git post-commit hook on the developer's machine
2. build — CI build step
3. deploy — CI deploy step

There is no way to:

• Add, remove, or rename pipeline steps
• Restrict which signing key is allowed to sign which step
• Accommodate pipelines that have more or fewer steps (e.g. a test step, a separate lint step, or a mono-repo with multiple build jobs)

Proposed Solution

Make the supply chain layout configurable per asset (or per organization), with sensible defaults:

Default behaviour (unchanged): the three-step layout (post-commit, build, deploy) is enforced, and any asymmetric personal access token that is valid for the asset is accepted as a signing key for any step.

Configurable options:

1. Steps — allow defining an ordered list of named pipeline steps. Each step should specify:

   • name — identifier used when uploading links (--step)
   • expectedMaterials — which step's products are this step's materials (i.e. the chaining rule)
   • optional: whether the step is required or optional

2. Signing keys per step — allow restricting which tokens (or key fingerprints) are allowed to sign a given step. For example:

   • post-commit → only tokens belonging to human developer accounts
   • build / deploy → only CI service account tokens

   Default: any asymmetric personal access token that is valid for the asset is accepted for any step (current behaviour).

Why This Matters

Organizations with non-standard pipelines (additional steps, split build jobs, matrix builds) cannot use supply chain verification today because the fixed layout does not match their actual pipeline. Making the layout configurable unblocks these use cases while keeping the secure-by-default three-step pipeline for everyone else.

Acceptance Criteria

• Asset or organization settings allow defining a custom layout (steps + optional per-step key restrictions)
• If no custom layout is configured, the existing fixed three-step layout is used (no breaking change)
• Default signing key policy: any valid asymmetric personal access token for the asset is accepted
• The intoto verify endpoint validates links against the configured layout, not the hardcoded one
• devguard-ci-components CI templates are updated to accept a configurable step name

Start at the intoto verify endpoint and trace how the current hardcoded three-step layout is enforced. Then inspect the devguard-ci-components CI templates; done means custom layouts and per-step key restrictions work while the existing defaults remain unchanged.