fix(identity): validate section and setting names when saving profiles

[hezelin-work]

Problem

Profile updates accepted section and setting names that the identity server does not support.

Solution

Validate section and setting names before saving profiles.

Testing: added unit tests.

License

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[ashishrp-aws]

🤖 AI-assisted review at ea403fd.

Approving. Validating on save is the right place for this. Checking that the section name reads back as the same type and name, and isn't an Object.prototype member, closes the header-injection and prototype-key cases. assertSingleLine in the serializer is a good backstop, because it also covers comments carried over from the existing file. sectionNameRegex matches smithy's prefixKeyRegex name class. Since save() only writes the config file, where typed sections must match that class, "the SDK does not load such names" holds.

Non-blocking:

• The settings allowlist is a client-visible behavior change beyond names. save() now rejects the whole request if it contains any setting other than region/sso_account_id/sso_role_name/sso_session (or the three sso_* session fields). Before, extra settings were written. I couldn't verify that no IDE client (VS, JetBrains, Eclipse, VS Code) sends something like output or credential_process through updateProfile. Please confirm that, and add a line to the PR description and changelog alongside the name change.
• Setting [${name}] is not supported. echoes the raw client-supplied name into the error. Run it through the same control-character check, or truncate it, before echoing.
• Nit: typeof section.name !== 'string' runs after the !section.name presence check, so a non-string truthy name still reaches the regex. That's harmless, but the ordering reads oddly.