chore: prepare SignPath code signing (policy page, gated release steps)

[lippdev]

Summary

• docs/CODE_SIGNING.md: the code signing policy SignPath Foundation requires (what is signed, team roles, privacy). Marked as pending until the application is approved. Linked from both READMEs.
• release.yml: upload the unsigned build, submit it to SignPath, verify the Authenticode signature and publish the signed files. The steps only run on tag pushes and only once the SIGNPATH_* repository variables and secret exist, so current releases are unchanged.

🤖 Generated with Claude Code

[pullfrog]

Important

The signing gate can activate with incomplete SignPath configuration and fail tagged releases; please make the gate cover every required input.

Reviewed changes The release workflow's optional SignPath signing path, the post-signature validation/replacement steps, and the linked English/Portuguese policy documentation were reviewed.

• Release signing — Builds are uploaded, submitted to SignPath on tag pushes, verified with Authenticode, and then passed to the existing artifact and GitHub release steps.
• Policy documentation — docs/CODE_SIGNING.md documents the signed artifacts, release provenance, team roles, and privacy details.
• README links — Both README files link to the new policy page.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using GPT Luna ｜ 𝕏}

[pullfrog]

This condition only checks SIGNPATH_ORGANIZATION_ID, so configuring the organization before SIGNPATH_PROJECT_SLUG, SIGNPATH_POLICY_SLUG, or SIGNPATH_API_TOKEN makes the subsequent SignPath action run with incomplete inputs and fail the tagged release. The PR describes signing as gated on all repository variables and the secret; gate all signing steps on the complete configuration, or fail early with a clear setup error before publishing.

Technical details

# Complete SignPath configuration gate

## Affected sites
- `.github/workflows/release.yml:99-122` — the upload, submission, and replacement steps use the organization-only condition.

## Required outcome
- A tagged release must either execute the complete signing path with all required SignPath values or remain on the existing unsigned path; a partially configured repository must not fail during the release.

## Suggested approach
- Use a single job-level or step condition that verifies the organization, project slug, policy slug, and token are all configured, with an explicit setup failure if partial configuration is detected.