Fix: Correctly calculate URL-encoded length

[dtaniwaki]

Thank you for maintaining this wonderful tool. I've been using git-pr-release in our workflow and it has been incredibly helpful.

I noticed an issue (#103) where the GitHub Issue Search API query length validation wasn't working correctly. The problem was that the code was checking the raw string length against the 256 character limit, but GitHub's API actually applies this limit to the URL-encoded length of keywords only (qualifiers like repo: and is: don't count toward the limit).

This means when the query contains special characters like : or /, they get encoded as %3A and %2F, making the actual encoded string longer than expected. This could cause the query to fail even when the raw string appeared to be under the limit.

I've updated the code to properly calculate the URL-encoded length before batching the queries, and refactored the query building logic to be clearer about what's being counted. I also added tests to verify the encoding calculations and ensure that batched queries never exceed the limit, including edge cases with long repository names.

Hope this helps! Let me know if you'd like any changes.

[ohbarye]

Thank you for the detailed investigation and suggestion. I understand that we should exclude qualifiers from the calculation.

Regarding the URL encoding, I may not fully understand the issue yet. The SHAs passed to the q parameter consist only of [0-9a-f], so URL encoding doesn't change their length. Additionally, spaces simply become + (1 character). Given this, it seems we could calculate the length without using URI.encode_www_form_component at all.

With that in mind, wouldn't it be correct to simply subtract the qualifier length from the current calculation?

-if query.length + 1 + sha.length >= 256
+if (query.length + 1 + sha.length) - query_base.length >= 256

[dtaniwaki]

That makes sense. I will fix the code.