## Summary

Upgrade GitHub Actions to their latest versions to ensure compatibility
with Node 24, as Node 20 will reach end-of-life in April 2026.

## Changes

| Action | Old Version(s) | New Version | Release | Files |
|--------|---------------|-------------|---------|-------|
| `actions/checkout` |
[`v4`](https://github.com/actions/checkout/releases/tag/v4) |
[`v6`](https://github.com/actions/checkout/releases/tag/v6) |
[Release](https://github.com/actions/checkout/releases/tag/v6) |
main.yml, pull_request.yml, pull_request_label.yml |

## Context

Per [GitHub's
announcement](https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/),
Node 20 is being deprecated and runners will begin using Node 24 by
default starting March 4th, 2026.

### Why this matters

- **Node 20 EOL**: April 2026
- **Node 24 default**: March 4th, 2026
- **Action**: Update to latest action versions that support Node 24

### Security Note

Actions that were previously pinned to commit SHAs remain pinned to SHAs
(updated to the latest release SHA) to maintain the security benefits of
immutable references.

### Testing

These changes only affect CI/CD workflow configurations and should not
impact application functionality. The workflows should be tested by
running them on a branch before merging.

Signed-off-by: Salman Muin Kayser Chishti <[email protected]>

…le#125)

### Motivation

The documentation example was using a manual `mapKeys` closure instead
of the more concise `prefixKeys(with:)` convenience method provided by
the library.

### Modifications

Updated the code snippet in KeyMappingProvider.swift to use the
`prefixKeys(with:)` method.

### Result

The documentation example now correctly reflects the recommended and
most concise way to prefix keys.

### Test Plan

Documentation-only change. Verified the syntax in the code comment.

…ariables provider (apple#120)

### Motivation

Add support for 1, 0, and YES, NO boolean strings in
EnvironmentVariablesProvider. Support for YES and NO boolean strings was
not discussed in the original issue. From personal experience, I found
it interesting to include it. If rejected, I will remove it. I tried to
remain consitent with the existing decoders and the way they are used by
the provider.

Closes apple#110 

### Modifications

The EnvironmentVariablesProvider's bool decoder is configurable and can
be initialized with support for true/false, 1/0, yes/no, or any
combination of them.

### Result

Usage of EnvironmentVariablesProvider has not changed, but by default
all pairs of boolean strings are accepted when retrieving values as Bool
or BoolArray. Client code can configure the provider to use a bool
decoder with support only for true/false strings.

If it is more important to keep the behavior as it was, meaning default
support for true/false only in the provider, then I will modify the
default set for the EnvironmentVariablesProvider BoolDecoder.

### Test Plan

The decoder is tested with dedicated tests, and additional tests for
receiving a value from a provider were added to test the integration of
BoolDecoder with EnvironmentVariablesProvider.

Code is commented, and tests are green locally.

---------

Co-authored-by: Honza Dvorsky <[email protected]>

…e#121)