docs: correct what is editable on an immutable release

"Managing releases in a repository" claimed that only the title and
release notes can be edited after an immutable release is published.
Measured against a repository with immutable releases enabled, a
published release also accepts changes to its pre-release and latest
flags and stays immutable; what is rejected is uploading or deleting
assets and moving the tag. The allowlist also contradicted the concepts
page, which lists exactly those two protections.

Replace it with a denylist, and document on the concepts page that a
release can be published as a pre-release, verified over the public
download path a draft does not offer, and then promoted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Bgb78NQ4wnUob76NZETBAZ

Author: koistya

content/code-security/concepts/supply-chain-security/immutable-releases.md

@@ -29,6 +29,10 @@ Additionally, creating an immutable release automatically generates a **release
 
 If a release is immutable, you will see {% octicon "lock" aria-hidden="true" %} **Immutable**"  below the title on the release page.
 
+## What you can still change
+
+Immutability protects the assets and Git tag of a release. After an immutable release is published, you can still edit its title and release notes, and change whether it is marked as a pre-release or as the latest release.
+
 ## Best practices for publishing immutable releases
 
 We recommend you use the following workflow for publishing an immutable release.
@@ -39,6 +43,8 @@ We recommend you use the following workflow for publishing an immutable release.
 
 This ensures that all assets are in place before the release becomes immutable, preventing the need to work around immutability restrictions.
 
+Draft releases are not public, so their assets cannot be downloaded the way consumers download them. To check that path before you promote a release, publish it as a pre-release, verify the published assets, then edit the release to clear **This is a pre-release** and select **Set as latest release**.
+
 ## Next steps
 
 To learn how to enable immutable releases for your repository or organization, see [AUTOTITLE](/code-security/how-tos/secure-your-supply-chain/establish-provenance-and-integrity/prevent-release-changes).

content/repositories/releasing-projects-on-github/managing-releases-in-a-repository.md

@@ -81,7 +81,7 @@ If you @mention any {% data variables.product.github %} users in the notes, the
 {% ifversion immutable-releases %}
 
 > [!NOTE]
-> If you have enabled immutable releases for your repository, you can only edit the title and release notes after a release is published. See [AUTOTITLE](/code-security/concepts/supply-chain-security/immutable-releases).
+> If you have enabled immutable releases for your repository, you cannot add, replace, or delete assets, or move the tag, after a release is published. You can still edit the title and release notes, and change whether the release is a pre-release or the latest release. See [AUTOTITLE](/code-security/concepts/supply-chain-security/immutable-releases).
 
 {% endif %}