fix: Separate stacked securityDefinitions into distinct comment groups

swag v2.0.0-rc5's parseSecAttributesV3 resolves a security scheme's map key
via getSecurityDefinitionKey(lines), which scans from the start of whatever
comment-line slice it was handed and returns the first @securitydefinitions
match — ignoring the current parse position entirely. Three
@securityDefinitions.apikey blocks stacked in one Go comment group (the
three were separated only by bare '//' lines, which do not split an
ast.CommentGroup) therefore all resolved to the first block's name
(cookieAuth), with the last block's in/name/description winning: the
generated document had exactly one securityScheme, keyed cookieAuth, body
esoAuth.

Separating the three blocks with real blank source lines splits them into
three distinct ast.CommentGroups, so swag's file-level comment scan (which
requires no other tokens between them, same rule Go uses for doc comments)
hands each block its own line slice and each resolves its own key.
Regenerated openapi.json now carries all three schemes with correct
bodies, referenced with no dangling security requirements.

server/internal/api/docs/openapi.json

@@ -2002,7 +2002,18 @@
             }
         },
         "securitySchemes": {
+            "bearerAuth": {
+                "description": "An API token, sent as \"Bearer vt_…\". Scoped and optionally expiring.",
+                "in": "header",
+                "name": "Authorization",
+                "type": "apiKey"
+            },
             "cookieAuth": {
+                "in": "cookie",
+                "name": "km_session",
+                "type": "apiKey"
+            },
+            "esoAuth": {
                 "description": "The External Secrets read token, rotated under Settings. It reaches /api/secrets/{group}/values and nothing else. It is a different credential from an API token, and the two must never be substituted for one another.",
                 "in": "header",
                 "name": "Authorization",