feat: add CI job to build/validate openshell.spec

[politerealism]

Part of: #3511

User Story

As a maintainer of openshell.spec, I want CI to actually build the package (not just grep its text), so future changes to the codebase or spec don't silently break Fedora buildability again.

Problem Statement

tasks/scripts/test-packaging-assets.sh only performs string-content assertions against openshell.spec (e.g., checking that certain lines are present) — it never actually invokes rpmbuild or mock against the spec. No CI workflow anywhere in .github/workflows/ builds the RPM from source.

Impact / Why This Matters

Once the rest of the Fedora packaging work lands, there's nothing stopping a future change (e.g., adding a new dependency, renaming a binary, changing feature flags) from silently breaking the Fedora build again, since nothing actually exercises it. This overlaps with the already-open #3454 ("test DEB and RPM installation profiles"), which should build/install the RPM at minimum.

Proposed Design

Add a packaging CI job using mock inside a container, following the existing license-headers-style job structure in .github/workflows/branch-checks.yml as a template, per the pattern already used for other spec-string checks in test-packaging-assets.sh.

Acceptance Criteria

• A CI job builds openshell.spec in a mock (or equivalent containerized Fedora) environment with networking disabled after %prep
• The job runs on changes to openshell.spec, Cargo.toml/Cargo.lock, deploy/rpm/, and relevant python/openshell/ sources
• Coordinated with ci(qualification): test DEB and RPM installation profiles #3454 rather than duplicating its scope

Alternatives Considered

• Rely on periodic manual builds — rejected; this is exactly the kind of check that silently rots without automation, as evidenced by the current spec already being broken.
• Only test via Fedora's own Rawhide/COPR builds post-merge — rejected as too late; want to catch build breaks before merge, not after.

[politerealism]

Consolidating this into the parent tracking issue #3509 as a listed work item rather than keeping it as a separate issue. Closing this one — see #3509 for the current text.