docs: prepare SignPath signing readiness

[Lee-take]

What changed

• add a public code-signing policy with named authors, reviewers, approver, MFA, manual approval, provenance, two-stage signing, verification, and incident boundaries
• add a privacy policy covering local storage and current user-triggered network routes
• expose both policies from the English and Chinese project homepages
• correct the documented v1.0.2 installer size and SHA-256 to the live immutable GitHub asset
• extend the deterministic release-source guard so signing and privacy readiness cannot silently regress

Why

DS Agent needs an origin-verifiable Authenticode path before a future Windows release can be represented as signed. This prepares the public repository for a SignPath Foundation open-source application without adding guessed provider identifiers, signing tokens, private keys, release automation, or signed-release claims.

Current v1.0.2 remains unsigned. No tag, release, installer, C1B branch, Step 2 branch, or PR #10 is changed by this PR.

Validation

• npx pnpm@9.15.9 test
  • frontend production build passed
  • Node and static contract tests passed
  • Rust: 877 passed, 0 failed, 7 ignored
• cargo fmt --manifest-path apps/desktop/src-tauri/Cargo.toml -- --check
• node scripts/release-source-check.mjs
• node scripts/secret-scan.mjs (209 files; 5 self-tests)
• node scripts/release-local-check.mjs --self-test
• git diff --check
• git diff --cached --check

External follow-up

After this documentation is reviewed and present on the default branch, submit the project to SignPath Foundation. Actual signing workflow identifiers and API credentials must be added only after SignPath assigns them. A release remains blocked until both the application executable and NSIS installer independently verify as Authenticode Valid.