ci: switch from SLSA provenance to actions/attest; update provenance docs

[keelerm84]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

N/A — CI and documentation-only changes, no application code or tests affected.

Related issues

Supports the org-wide migration to immutable GitHub releases. Reference implementation: launchdarkly/ld-relay.

Describe the solution you've provided

GitHub's immutable releases feature prevents modifying a release after it is published. This repo only uses attestation (no binary/artifact uploads to the release), so draft releases are not needed — actions/attest@v4 stores attestations via GitHub's attestation API rather than as release assets.

Changes:

1. SLSA → actions/attest@v4 with subject-path (both workflows): Replaced the separate release-provenance job (which used slsa-framework/slsa-github-generator with upload-assets: true) with inline actions/attest@v4 steps. Attestation uses subject-path to reference the gem file directly on disk, eliminating the base64 encode/decode hash round-trip entirely.

2. Removed hash outputs from composite action: The gem-hashes output and hash computation step were removed from .github/actions/publish/action.yml since subject-path reads files directly.

3. Removed dead tag_name output from release-please.yml — no longer consumed after the release-provenance job was removed.

4. Dry-run guard: Attestation steps use format('{0}', inputs.dry_run) == 'false' to safely handle the boolean/string mismatch between workflow_call (boolean) and workflow_dispatch (string) triggers.

5. PROVENANCE.md: Rewrote to use gh attestation verify ... --owner launchdarkly instead of slsa-verifier. Sample output follows the real gh attestation verify format including policy criteria and attestation details.

6. README.md: Updated provenance section heading and description to reference GitHub artifact attestations instead of SLSA framework.

Describe alternatives you've considered

• Draft releases with publish-release job: Unnecessary since actions/attest@v4 does not upload assets to the GitHub release.
• subject-checksums with base64 round-trip: Worked but was unnecessarily complex. subject-path is simpler since the gem is on disk in the same job.
• -R launchdarkly/ruby-server-sdk in verify command: Chose --owner launchdarkly for consistency across all SDK repos.

Additional context

Items for human review

• Verify subject-path glob (launchdarkly-server-sdk-*.gem) matches the gem file produced by gem build in the composite action, and that the file is in the expected working directory when the attest step runs.
• format('{0}', inputs.dry_run) == 'false' — confirm this correctly handles both boolean and string inputs across trigger types.
• PROVENANCE.md sample output is representative (based on real output from ld-relay), not captured from this repo. Verify after first attested release.
• Confirm no downstream consumers depend on the removed .intoto.jsonl release asset or the removed tag_name job output.

Link to Devin session: https://app.devin.ai/sessions/7d5bda4d9dbe4ae0b950b30a50485e60
Requested by: @keelerm84