[DOC] Document Obsidian Publish browser-security header limitations

## Documentation Request

Document the production security-header boundary for blogs.comphy-lab.org and the work needed to harden it without breaking Obsidian Publish.

The live site sends a provider-generated CSP that permits inline/eval execution, wildcard HTTPS sources, plaintext HTTP/WS connections, and broad framing. It has no effective clickjacking restriction. /.well-known/security.txt returns the normal HTML application rather than an RFC 9116 text response.

## Purpose

AGENTS.md:82-88 correctly identifies Obsidian Publish as the serving platform, but the repository does not say which browser-security controls are provider-owned and which can be safely overlaid at Cloudflare. Without that boundary, a future cleanup can either leave the gap invisible or apply a strict CSP that breaks the published site.

## Suggested Content

Record the observed provider CSP, the features that require each allowed source, and whether a Cloudflare response-header rule or small edge Worker can safely tighten framing, referrer, permissions, and connection policies. Include a staged browser check before any CSP change. Serve a correct /.well-known/security.txt response at the edge if Obsidian Publish cannot own that path.

## Additional Context

This issue is a documentation and design record first. No provider or Cloudflare setting has been changed, and a stricter CSP has not yet been compatibility-tested.

Start with AGENTS.md sections 82-88, then inspect the live site's security headers and /.well-known/security.txt response. Document the observed CSP, provider-owned versus safely overridable controls, required compatibility checks, and the edge approach for security.txt; done means the boundary and staged hardening plan are recorded without changing provider or Cloudflare settings.

Written by the indexing model from the issue text.