Standardize README security policy section

[Copilot]

Updates README.md to use the standardized Security Policy wording for zenstruck/browser, with the repository-specific security URL expressed as a Markdown link.

• README

  • adds/replaces the ## Security Policy section with the approved standardized copy
  • points readers to the repo’s security policy page at https://github.com/zenstruck/browser/security
  • preserves the existing README structure and formatting

• Result

  • aligns zenstruck/browser with the requested SymfonyCasts-style security disclosure guidance
  • avoids public vulnerability reporting instructions in favor of the repository security policy

## Security Policy

If you discover a security vulnerability, please do not open a public issue or pull request. Instead, please review this repository's [Security Policy](https://github.com/zenstruck/browser/security) for instructions on how to report it responsibly.

Original prompt

Create exactly one pull request for zenstruck/browser to update its README Security Policy section.

Requirements:

1. Work only on zenstruck/browser for now.
2. Use a fork owned by copilot. Do not create any branch on the upstream zenstruck/browser repository.
3. Open a non-draft pull request from the copilot fork to the upstream repository.
4. Update the README so the Security Policy section matches the SymfonyCasts example in meaning and wording, but with the repository-specific security link for zenstruck/browser.
5. The security URL must be a Markdown link.
6. If the README already has a security policy section, replace it with the standardized section. Otherwise add it.
7. Preserve existing README formatting.

Use this exact section text:

Security Policy

If you discover a security vulnerability, please do not open a public issue or pull request. Instead, please review this repository's Security Policy for instructions on how to report it responsibly.

Important constraints:

• PR must be non-draft.
• PR head must come from the copilot fork, not a branch on zenstruck/browser.
• Only create the PR for zenstruck/browser.
• The user will review this single PR before any broader rollout.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: I'd like to update zenstruck packages readmes to add a security policy section.

1. all public, non-archived zenstruck packages that are also on packagist.org
2. should read exactly like what was made @SymfonyCasts/dynamic-formsAllow Browser::click() to work with css selector #60 (but with the link changed to the specific repo)
3. A non-draft PR for each using a fork (to be reviewed and merged by me)
4. If a readme already has a security policy, replace with this
   Anything else for me to confirm?

Assistant: Yes: I have enough to proceed except for one important confirmation.

I can use the exact section text from SymfonyCasts/dynamic-forms PR #60, with only the repo-specific security-policy link changed. I also identified the zenstruck org and its public repos.

What I need you to confirm is:

1. Use your fork for every target repo?
   Since you want “a non-draft PR for each using a fork,” I need your confirmation that I should open PRs from your forked branches rather than direct branches on zenstruck/*.

2. Scope of repos:
   I’ll target only repos that are:

   • public
   • non-archived
   • in the zenstruck org
   • also on Packagist
   • and have a README to update

3. Include or exclude infra/template repos?
   Some public non-archived repos likely are not package repos, such as:

   • zenstruck/.github
   • zenstruck/ci-test
   • zenstruck/php-template

   I plan to exclude anything not actually on Packagist, which should naturally remove those, but if you want any extra exclusions, say so now.

If that all sounds right, reply with something like:

Yes — use my forks, limit to Packagist packages only, exclude non-package repos.

Then I’ll create the PRs.

User: 1. I want it to be forked to copilot (not kbond) and the PR opened from your fork. I don't want branches created on the zenstruck repos
2. Scope is good
3. No

Assistant: We’re waiting on your approval of the requested GitHub action, and once you respond to that prompt I can continue.

User: @copilot Accepted Confirmation: Confirm cloud agent session

Assistant: Started — I’ve kicked off the work to create the PRs from the copilot forks.

You can track progress here:
https://github.com/copilot/tasks/pull/PR_kwDOD9YODc7hwSRW?session_id=2795e5da-62d0-455c-9896-84f19cbf2280

User: can I approve the rest of the agent sessions? (for the other repos)?

Assistant: Yes — please approve the remaining agent sessions for the other repositories as they appear.

Each repo needs its own fork/branch/PR flow, so those confirmations are expected. Once approved, I can continue opening the non-draft PRs from the copilot forks.

User: when can I see the approval boxes?

Assistant: You’ll see them when the agent reaches the step that needs permission for each repository — typically when it’s about to create or use the copilot fork / open the PR.

If you don’t see them yet, that usually means the agent is still:

• identifying eligible repos,
• checking the README/security-policy state,
• or preparing the changes.

They should appear progressively, not all at once. The best place to watch is the task page I linked earlier; as the agent advances repo by repo, GitHub should surface the approval prompts there. If one repo finishes and no new prompt appears after a bit, refresh the task page.

User: Ok, I see you created the one for foundry. I have some modifications to make before proceeding with the others:

1. The foundry PR is a draft, I asked for non-drafts
2. The link should be a markdown link

Assistant: Understood.

I’ll c...

This pull request was created from Copilot chat.