fix: Api defintion queries do not treat path as literal

[oechsler]

Issue

Currenty, queries the ApiDefinition class treat paths with a . in the name (such as /example.html) as nested properties. This results in a validation errors because the underling lodash get/set/has tries to access .html as a nested property of example instead of recognizing it as part of the path. For instance, a query like paths[/example.html].get searches for a get method inside a nested html property on example, rather than accessing paths['example.html'].get. Due to this mismatch it is not possible to define siad paths with file extensions using this construct, even though the OpenApi allows for such endpoints to be exist.

Fix

By updating the queries to use the input ${path} as a literal, this PR ensures that endpoint paths are treated accurately, allowing paths with file extensions (such as /example.html) to be correctly processed by the construct.