docs: add SECURITY.md with the vulnerability reporting policy

Start by reviewing the security policy in backblaze-labs/b2-mcp, the repository's Go module and request logging behavior, and the related RELEASE.md, zizmor, and branch rename issues. Draft root SECURITY.md with the requested Go specific reporting, scope, credential, supply chain, and incident response policies, then verify its links and claims with maintainers. Done means the document is merged, GitHub detects it as the repository security policy, and the private reporting and contact paths are verified.

Add a SECURITY.md at the repo root with the vulnerability reporting policy for blazer as a Go module. It should be adapted from the security policy in backblaze-labs/b2-mcp, keeping the structure (supported versions, private reporting, response expectations, scope, secret handling, credential trust boundary, supply-chain incident response) and replacing the MCP and npm specifics with Go library equivalents. GitHub shows SECURITY.md in the Security tab and links it from new issues, and there is currently none.

Sections to include:

• Ownership: Backblaze Security as the response owner, plus the repository security reviewers (names to be filled in by maintainers).
• Supported versions: only the latest minor release line is supported (blazer is v0, so for example 0.9.x once released); earlier releases are not patched in place, and consumers such as restic should upgrade. Link to the support policy in RELEASE.md (see the RELEASE.md issue).
• Reporting: do not file a public issue. Use GitHub Security Advisories on Backblaze/blazer (Security tab, Report a vulnerability), or email [email protected] if that is not possible. Ask for a description, reproduction steps (ideally a minimal Go program), affected versions and impact.
• What to expect: acknowledgement within 3 business days, initial assessment within 7 business days, coordinated disclosure once a fix is released. For confirmed issues, publish a GitHub Security Advisory with a CVE, ship the fix in a new tagged version, add a retract directive for the affected versions where appropriate, and submit the report to the Go vulnerability database (golang.org/x/vulndb) so govulncheck flags it for downstream users.
• Scope, in: credential handling flaws (application keys, auth tokens, upload and download tokens, SSE-C customer keys), token leakage through logs, errors or URLs, TLS or certificate validation weaknesses, request smuggling or header injection through file names and file info, path or URL escaping bugs that address the wrong object (for example in Object.URL and Object.AuthURL), integrity bypasses such as skipped or wrong SHA-1 verification, and denial of service or unbounded resource use reachable through the public API (retry loops, goroutine leaks, unbounded buffering).
• Scope, out: vulnerabilities in the Backblaze B2 service itself (report to Backblaze directly), misconfiguration in the consuming application (for example logging at the highest B2_LOG_LEVEL in production, committing keys, overly broad application key capabilities), issues requiring local access to the machine running the program, and vulnerabilities in the Go toolchain or standard library (report to the Go security team).
• Secret handling policy for a library: blazer receives the plaintext application key, so document that the key and tokens must never appear in logs, errors or panics; the existing request logging redacts authorization tokens and this should be stated as a guarantee with tests; presigned or authorized URLs (AuthURL puts the token in the query string) are bearer credentials and must be treated as secrets until they expire; SSE-C keys must be redacted from every String, GoString, JSON and log path once file-level encryption is added.
• Credential trust boundary: describe what blazer talks to (api.backblazeb2.com, the returned API, upload and download hosts), that TLS is delegated to the supplied http.RoundTripper (default http.DefaultTransport), and that callers who inject a transport own its security.
• Dependency and supply-chain policy: blazer currently has no third-party dependencies (empty go.sum), which is a property to preserve; any new dependency is a reviewed change. Document govulncheck ./... in CI, go mod verify, GOFLAGS=-mod=readonly, pinned GitHub Actions (see the zizmor issue), and signed tags (see the RELEASE.md issue).
• Incident response: if a leaked key or compromised release is suspected, rotate the affected B2 application keys, retract the affected version, publish a fixed version and an advisory, and notify known downstream consumers.

Acceptance: SECURITY.md is merged and detected by GitHub (Security policy appears in the repo Security tab), private vulnerability reporting is enabled in repository settings, and the contact path in the document has been verified to reach the right team.

Related: the RELEASE.md issue (#94), #93 (zizmor), and #92 (rename master to main; use the new branch name in links).