fix!: URL-encode path parameters in generated endpoints

[Robbie-Palmer]

Summary

Path parameters containing reserved characters were being inserted directly into URLs without encoding, causing malformed requests and potential security issues.

Problem

When path parameters contain special characters like:

• Slashes (/)
• Question marks (?)
• Ampersands (&)
• Hash/fragments (#)
• Spaces

These were not being URL-encoded, leading to:

• Malformed URLs that break routing
• Security vulnerabilities where parameter values could inject path segments
• Non-compliance with RFC 3986

Solution

• Import urllib.parse.quote in the endpoint template
• Wrap all path parameters with quote(str(...), safe="") to ensure proper percent-encoding
• Add comprehensive tests for various special characters in path parameters

Changes

• Updated openapi_python_client/templates/endpoint_module.py.jinja to add URL encoding
• Added end_to_end_tests/functional_tests/generated_code_execution/test_path_parameters.py with tests
• Regenerated all golden records to reflect the encoding changes

Test plan

• Added test for normal alphanumeric path parameters (baseline)
• Added tests for path parameters with reserved characters (/, ?, &, #)
• Added tests for path parameters with spaces
• Regenerated golden records with pdm regen
• Verified generated code properly encodes all special characters

Example

Before:

"url": f"/items/{item_id}/details/{detail_id}"
# With item_id="item/with/slashes" becomes:
# "/items/item/with/slashes/details/..." (broken!)

After:

"url": "/items/{item_id}/details/{detail_id}".format(
    item_id=quote(str(item_id), safe=""),
    detail_id=quote(str(detail_id), safe=""),
)
# With item_id="item/with/slashes" becomes:
# "/items/item%2Fwith%2Fslashes/details/..." (correct!)

[dbanty]

Seems like the right call, though I will mark as a breaking change since someone was probably relying on the previous unsafe behavior 😓.

Thanks!