feat: reproducible source/vendor tarball generation script for Fedora packaging #3514

Part of: #3511

User Story

As a Fedora packager maintaining openshell.spec across version bumps, I want a single script that reproducibly regenerates Source0 (source tarball) and Source1 (vendor tarball), so every release can be re-packaged consistently and reviewers can verify how the sources were produced.

Problem Statement

No such script exists in this repo today. An internal RHEL9 midstream spec (built externally) references an equivalent make-sources.sh process, but nothing comparable is checked into NVIDIA/OpenShell.

Impact / Why This Matters

Fedora package review requires packagers to be able to explain and reproduce exactly how Source0/Source1 were generated — this is a standard reviewer question. Without a script, every version bump becomes an ad hoc, undocumented manual process, and generating Python proto stubs needs to happen at this same step rather than scattered across multiple manual commands.

Proposed Design

A single shell script, invoked with a version/git-ref argument, that: archives the given ref, patches the workspace version placeholder, runs proto generation, creates the source tarball, then runs cargo vendor vendor and tars that separately. Mirrors the shape of the existing tasks/scripts/package-deb.sh / stage-prebuilt-binaries.sh scripts in style and location.

Acceptance Criteria

• A script (e.g. tasks/scripts/make-fedora-sources.sh) produces openshell-<version>.tar.gz and openshell-<version>-vendor.tar.xz from a given git ref
• The source tarball includes generated Python proto stubs
• The vendor tarball is produced via cargo vendor against the workspace Cargo.lock
• Script is documented (inline or README) with usage instructions referenced from openshell.spec's header comment

Alternatives Considered

• Rely on generic Fedora tooling to fetch sources ad hoc per build — rejected; Fedora's own guidelines still expect a documented, reproducible process for how the vendor tarball was produced, and ad hoc generation at review time doesn't give reviewers or future packagers something to re-run themselves.
• Do this manually each release — rejected as unsustainable and error-prone, especially combined with the proto-stub generation step.