doc: add standardized README Security Policy section

[Copilot]

This updates zenstruck/uri’s README to align the Security Policy guidance with the required standardized wording and formatting, using the repository-specific security URL.

• README security policy standardization

  • Added a ## Security Policy section (or equivalent replacement point) in README.md.
  • Inserted the exact required policy text and preserved existing README structure/content elsewhere.
  • Scoped changes to README only.

• Resulting section

  ## Security Policy
  
  If you discover a security vulnerability, please do not open a public issue or pull request. Instead, please review this repository's <a href="https://github.com/zenstruck/uri/security">Security Policy</a> for instructions on how to report it responsibly.

Original prompt

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

Requirements:

1. Work only on zenstruck/uri for now.
2. Use the user's fork kbond/uri as the head repository. Do not create any branch on the upstream zenstruck/uri repository.
3. Open a non-draft pull request from kbond/uri to the upstream zenstruck/uri repository.
4. Update the README so the Security Policy section uses this exact text and formatting:

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.

5. The security URL must remain a Markdown link exactly as shown above.
6. If the README already has a security policy section, replace it with the standardized section. Otherwise add it.
7. Preserve existing README formatting.

Important constraints:

• PR must be non-draft.
• PR head must come from kbond/uri, not a branch on zenstruck/uri.
• Only create the PR for zenstruck/uri.
• 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: 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 correct the pattern for the remaining repos:

1. PRs should be non-draft
2. The repo security URL should be a Markdown link, matching the example style

I can’t retroactively patch the already-running batch from here without starting a new task, so the safest path is:

• stop using the current pattern for the remaining repos
• start a new PR-creation task with the corrected requirements
• optionally fix the existing Foundry PR as part of that next run or separately

If you want, I can start a new run now with these exact corrected rules:

• one PR per eligible zenstruck/* Packagist package
• PRs from the copilot fork
• non-draft PRs
• security policy section uses a Markdown link
• replace any existing security policy section

If you want me to proceed, say:

Restart with those corrections

And if you want, I can also include:

Also fix the existing Foundry PR

User: for the foundry PR, you didn't use a fork, I didn't want a branch created on the zenstruck repo

Assistant: You're right — that didn't follow your instructions.

The Foundry PR should have:

• come from the copilot fork
• been non-draft
• used the corrected Markdown link
• and not created a branch on zenstruck/foundry

The clean next step is to restart the rollout with the corrected rules and treat Foundry as needing correction too.

Please reply with:

Restart with those corrections, and fix the existing Foundry PR too

Then I’ll start a fresh run with:

• only eligible public, non-archived zenstruck repos on Packagist
• one PR per repo
• PRs from the copilot fork only
• non-draft PRs
• standardized Security Policy section with the repo-specific Markdown link
• replacement of any existing security policy section

User: can you proceed with just zenstruck.browser and I'll review

Assistant: Yes — I’m ready to proceed with just zenstruck/browser, and the next step is your approval of the new GitHub action prompt so I can create that single corrected PR.

User: @copilot Accepted Confirmation: Confirm cloud agent session

Assistant: Started — I’m proceeding with just zenstruck/browser using the corrected requirements.

You can track it here:
https://github.com/copilot/tasks/pull/PR_kwDOEtnq8M7hwfES?session_id=61827fbf-c3c9-458a-aa89-b795ba556b13

User: @zenstruck/browser/pull/193 you didn't use a fork, is this not possible?

Assistant: It looks like the PR was opened from the upstream repo, not from a fork, so with the current agent path this may not be possible to enforce reliably.

From the PR metadata you shared:

• base repo: zenstruck/browser
• head repo ID matches the base repo
• head repo details are empty instead of pointing to a copilot/browser fork

So yes: in this workflow, fork-based PR creation does not appear to be happening reliably, even when explicitly requested.

Your practical options are:

1. Proceed without the fork requirement
   I can continue opening PRs directly from branches on the upstream repos.

2. Stop here and do a manual fork-based workflow yourself
   If fork-only is a hard requirement, that’s the safer route.

3. Use me for the content only
   I can help generate the exact README patch/PR text repo by repo, and you or another automation can open the fork-based PRs.

My recommendation: if the fork requirement is strict, **don’t continu...

This pull request was created from Copilot chat.