fix: correct update.sh script help

[MikeMcC399]

• closes update -h script help option non-working examples #2412

Description

In the update.sh script, update example options to use current Node.js versions and latest Debian release (trixie) and ensure the accuracy of examples.

Motivation and Context

The help text invoked with ./update.sh -h has several inaccuracies.

• specifying EOL Node.js versions, such as 8, attempts to update all current versions
• specifying . alpine on its own also attempts to update all variants
• specifying -s 8 bullseye updates all versions

The combination of -s and Debian variants is redundant. ./update.sh 24 trixie, for example, does not fail when the musl checksum is missing, so adding -s is not needed.

Testing Details

Execute ./update.sh -h and then invoke each one of the listed examples. Confirm that the logs are consistent with the help description.

Example Output

$ ./update.sh -h

  Update the node docker images.

  Usage:
    ./update.sh [-s] [MAJOR_VERSION(S)] [VARIANT(S)]

  Examples:
    - update.sh                           # Update all images
    - update.sh -s                        # Update all images, skip updating Alpine if the musl build is unavailable
    - update.sh 22,24                     # Update all variants of version 22 and 24
    - update.sh -s 24                     # Update all variants of version 24, except skip updating Alpine if the musl build is unavailable
    - update.sh 24 alpine3.22,alpine3.23  # Update only alpine3.22 & alpine3.23 variants for version 24
    - update.sh . trixie,trixie-slim      # Update only trixie & trixie-slim Debian variants for all versions

  OPTIONS:
    -s Security update; allows Debian updates even if musl build for Alpine is unavailable
    -h Show this message

Types of changes

• Documentation
• Version change (Update, remove or add more Node.js versions)
• Variant change (Update, remove or add more variants, or versions of variants)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Other (none of the above)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING.md document.
• All new and existing tests passed.