v0.6.1

Aegis 0.6.1 sharpens two detectors and rebuilds the release pipeline on
GitForge. The Dockerfile secret detector now anchors its matches to actual
Dockerfile directives, and the CI-bypass detector gained precision fixes that
cut false positives on legitimate workflow files. The release process itself
changed: every asset — five platform tarballs, the WASM module, source
archives, checksums, and a new build attestation — is built by the GitForge
pipeline and mirrored to this release, with checksums.txt now covering the
complete published set. Release titles are the bare version tag.

Changed

• Releases are built by the GitForge pipeline (.gitforce.yml) and synced
  to the GitHub release by scripts/release/publish.sh; the GitHub
  Release workflow remains as a manual-dispatch fallback running the same
  scripts. Every release now ships attestation.json
  (aegis.release-attestation/v1) recording the tag, commit, builder
  platform, toolchains, and the SHA-256 of every other asset, and the WASM
  asset is published as aegis-wasm.wasm — previously the crate-mangled
  aegis_wasm.wasm — to match the aegis-<target> naming of the platform
  archives. Release titles are the bare tag. darwin binaries are
  cross-linked with zig on the build host rather than built on Apple
  hardware; the attestation states this instead of hiding it.

Fixed

• The secrets-in-dockerfile rule is anchored to line-oriented Dockerfile
  directives — ^\s*(ARG|ENV)\s+… under multiline matching, where it
  previously matched ARG/ENV and a secret-ish word anywhere in a file —
  so Rust, Markdown, and test prose containing words like ENV or TOKEN
  are no longer reported as Dockerfile secrets.
• The ci-bypass rule now requires explicit bypass syntax (--no-verify,
  continue-on-error: true, or a direct verb–target pairing such as
  skip tests) and fires only in CI, configuration, and shell file types,
  instead of flagging any line of prose where a bypass-like word appears
  near a CI-like one.