ci: enforce TLS for authenticated resource writes

[Jeremy1844]

Summary

• require repository-local Git TLS certificate verification in the two authenticated resource-write workflows
• add a focused policy regression covering both workflows
• leave the existing remote, credential transport, commands, content, and deployment targets unchanged

Root cause

Both authenticated write paths explicitly set http.sslVerify to false. That makes Git accept a server connection whose certificate chain cannot be verified. The workflows now set repository-local http.sslVerify=true, so trust failures stop the operation instead of bypassing verification.

This draft addresses only ADV-2026-0056 / RC-0056. Credential lifetime and transport, dispatch validation, action provenance, and permissions remain separate roots.

Evidence

• regression-first base result: 0/2 policy cases pass
• fixed branch result: 2/2 policy cases pass
• both edited workflows parse with js-yaml 4.1.0
• git diff --check passes
• protected src, assets, ops, package, and lock objects are unchanged
• added-line secret scan reports zero candidates
• draft fix: make resource validation read-only and fail closed #76 has zero path overlap and composes cleanly
• draft ci: fix resource workflow path filters #77 shares deploy-assets.yml but edits only the path-filter hunk; the exact combined tree composes cleanly and passes 5/5 focused cases plus YAML/diff/protected-tree/secret gates

Operational notes

There is no user-data, schema, artifact, or content migration. If a runner or proxy lacks the required CA chain, the safe response is to pause the authenticated writer and repair trust at the runner/platform boundary. Restoring sslVerify=false is not a safe rollback.

No authenticated staging fetch/push, hosted-runner CA validation, or invalid-certificate negative test was performed. Those remain maintainer-owned pre-merge gates, and the invalid-certificate test must use an isolated staging endpoint rather than production.