[management] Fix extended config when nil

[mlsmaycon]

Describe your changes

Issue ticket number and link

Checklist

• Is it a bug fix
• Is a typo/documentation fix
• Is a feature enhancement
• It is a refactor
• Created tests that fail without the change (if possible)
• Extended the README / documentation, if necessary

[Copilot]

Pull Request Overview

This PR addresses a bug fix to properly handle cases where the extended configuration is nil by ensuring that the updated Netbird configuration is correctly assigned after extending it.

• In management/server/token_mgr.go, the extended configuration is now captured in a variable and then assigned back to update.NetbirdConfig.
• In management/server/grpcserver.go, a similar approach is applied where the extended configuration is stored in a variable before being set on the response.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
management/server/token_mgr.go	Assigns the returned extended configuration explicitly to update.NetbirdConfig
management/server/grpcserver.go	Captures and assigns the extended configuration to response.NetbirdConfig

Comments suppressed due to low confidence (2)

management/server/token_mgr.go:261

• [nitpick] Consider using a more descriptive variable name (e.g., 'updatedNetbirdConfig') to improve clarity, especially if this value is used in multiple contexts.

extendedConfig := integrationsConfig.ExtendNetBirdConfig(peerID, update.NetbirdConfig, extraSettings)

management/server/grpcserver.go:640

• [nitpick] For consistency with similar changes in the codebase, consider renaming the variable to better reflect that it holds the updated Netbird configuration.

extendedConfig := integrationsConfig.ExtendNetBirdConfig(peer.ID, nbConfig, extraSettings)

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud