Clarify SEP numbering (modelcontextprotocol#1045)

Author: nickcoai

docs/community/sep-guidelines.mdx

@@ -44,9 +44,9 @@ Each SEP must have an **SEP author** -- someone who writes the SEP using the sty
 
 SEPs should be submitted as a GitHub Issue in the [specification repository](https://github.com/modelcontextprotocol/modelcontextprotocol). The standard SEP workflow is:
 
-1. You, the SEP author, create a [well-formatted](#sep-format) GitHub Issue with the `SEP` and `proposal` tags. Do not assign an SEP number; one will be assigned by the SEP sponsor.
+1. You, the SEP author, create a [well-formatted](#sep-format) GitHub Issue with the `SEP` and `proposal` tags. The SEP number is the same as the Github Issue number, the two can be used interchangably.
 2. Find a Core Maintainer or Maintainer to sponsor your proposal. Core Maintainers and Maintainers will regularly go over the list of open proposals to determine which proposals to sponsor.
-3. Once a sponsor is found, the GitHub Issue is assigned to the sponsor. The sponsor will add the `draft` tag, assign a unique SEP number, and assign a milestone.
+3. Once a sponsor is found, the GitHub Issue is assigned to the sponsor. The sponsor will add the `draft` tag, ensure the SEP number is in the title, and assign a milestone.
 4. The sponsor will informally review the proposal and may request changes based on community feedback. When ready for formal review, the sponsor will add the `in-review` tag.
 5. After the `in-review` tag is added, the SEP enters formal review by the Core Maintainers team. The SEP may be accepted, rejected, or returned for revision.
 6. If the SEP has not found a sponsor within three months, Core Maintainers may close the SEP as `dormant`.