DLPX-98654 [linux-pkg] Add syft/cyclonedx-cli packages

[justsanjeev]

Background

Companion to DLPX-98637 (delphix/syft) and DLPX-98638 (delphix/cyclonedx-cli) under the
CP-13455 CycloneDX SBOM epic. appliance-build PR #892 (CP-13464) provisioned Syft and
cyclonedx-cli by downloading pinned releases directly from github.com at build time;
review feedback flagged that as against convention. Design doc: DLPX-98618
(appliance-build/docs/specs/2026-08-13-syft-cyclonedx-cli-provisioning-design.md).

Problem

Syft and cyclonedx-cli need to be installed onto the appliance-build host (never inside the
shipped image) to generate and validate a CycloneDX SBOM for each built appliance. Neither
had a first-party linux-pkg package, so linux-pkg had no way to provision them -- they
were fetched directly from github.com at appliance-build build time instead, which is
inconsistent with how every other third-party build-host tool is provisioned in this org.

Solution

Add syft and cyclonedx-cli to main.pkgs, each with a packages/<name>/config.sh
pointing DEFAULT_PACKAGE_GIT_URL at the new first-party packaging repos
(delphix/syft, delphix/cyclonedx-cli) and calling dpkg_buildpackage_default, following
the exact delphix-go/host-jdks pattern. Both are listed only in main.pkgs -- never in
any appliance-build chroot package list -- so they stay build-host-only and are never
shipped inside the appliance image (see the comments added next to each in main.pkgs).

Each config.sh also sets PACKAGE_VERSION from that repo's own single-source-of-truth
version file (SYFT_VERSION / CYCLONEDX_VERSION), following the delphix-rust/
RUSTC_VERSION pattern, instead of letting linux-pkg default it to 1.0.0. Without this,
the built .deb's own version would never reflect the pinned upstream release -- notably bad
provenance for tools whose entire purpose is provenance.

Testing Done

• packages/syft/config.sh / packages/cyclonedx-cli/config.sh follow the same shape as the
  existing delphix-go/host-jdks config files, which already build successfully through
  this same linux-pkg path.
• Real pre-push build-package Jenkins runs, both green, producing correctly-versioned
  .debs (previously would have defaulted to 1.0.0 regardless of pinned version):
  • syft: pre-push #3
    -> delphix-syft_1.46.0-1delphix.2026.08.25.12.54_amd64.deb
  • cyclonedx-cli: pre-push #3
    -> delphix-cyclonedx-cli_0.32.0-1delphix.2026.08.25.12.54_amd64.deb
• Downstream consumption validated in appliance-build PR #892: appliance-build-stage0
  pre-push Build multiple versions of the delphix-platform package #4 built using these packages, and the resulting CycloneDX SBOMs were reconciled
  against the existing BOM CSV across all 3 image variants with zero version mismatches (see
  that PR's Testing Done for the full comparison).

Related PRs:

• delphix/syft#1 and
  delphix/cyclonedx-cli#1 -- the packaging
  repos this PR wires up, reviewed and approved by @prakashsurya.
• delphix/appliance-build#892 -- the
  consumer of these packages.
• delphix/devops-gate#4787 -- registers
  the Jenkins PrePush Jira/style checks for the two new repos above (merged).

[prakashsurya]

looks reasonable to me.. I presume, these repos follow the product's branch conventions (e.g. develop, release, etc.)?