Kotlin samples using deprecated API

Describe the bug

The page about Kotlin Configuration for Servlet Applications suggests API that has been marked as deprecated.
https://docs.spring.io/spring-security/reference/servlet/configuration/kotlin.html

Deprecation:
Deprecated - For removal in 7.0. Use authorizeHttpRequests() instead

Since this is something that changes with 7.0 and the current release is 6.x, I know I can understand why the old way might be okay. But as far as I see, authorizeHttpRequests() is already supported in the current 6.x version, so I would assume this is also recommended to be used.

To Reproduce
authorizeHttpRequests

Expected behavior

This ties in with other issues like reported here https://github.com/spring-projects/spring-security/issues/13610 with code samples and Spring security.

Why not an easy task, it feel like keeping code samples updated is a solvable task. Spring offers SpringRestDocs, which has the same concept that could be applied here (not SpringRestDocs, but the same ideas):
Any documentation referencing code should have this code in the repository as well. When rendering the documentation, missing code samples trigger failed tests.
References to branches or outdated versions (see the referenced issue), trigger failed tests.
Errors when compiling or running the backing code trigger failed tests.
Usage of deprecated marked APIs trigger failed tests. (-> ArchUnit could help here)

If the 'backing' code is not polluted with things only relevant for being the documentation backing code (e.g. the suggested archunit tests), it might be even used as sample code itself. Or maybe not.

But a process that ensures the documentation match the current recommended practices would be very helpful.

Start with the Kotlin Configuration for Servlet Applications page and compare its samples with the current 6.x API, especially the deprecated API identified in the issue and authorizeHttpRequests(). Check issue #13610 for related documentation concerns; done means the affected samples use the recommended API, with the broader backing-code validation proposal clarified as in or out of scope.