fix(integrations): Handle ValueError for non-numeric organization_id in webhook parsers

[sentry]

This PR addresses SENTRY-5M2H, where webhook endpoints for integrations (specifically Bitbucket and legacy plugins) were crashing due to ValueError: invalid literal for int() with base 10.

Root Cause:
The URL patterns for these webhooks use (?P<organization_id>[^/]+) to capture the organization_id. While this allows for both numeric IDs and alphanumeric slugs, it also permits malformed values like '1,2,3'. When such a value was passed to OrganizationMapping.objects.get(organization_id=organization_id), the Django ORM attempted to convert '1,2,3' to an integer, resulting in a ValueError.

Solution:
Instead of tightening the URL regex (which could break legitimate slug usage), the fix involves gracefully handling the ValueError at the application level. The OrganizationMapping.objects.get() calls in BitbucketRequestParser.get_bitbucket_webhook_response() and PluginRequestParser.get_response() are now wrapped in a try-except block that catches both OrganizationMapping.DoesNotExist and ValueError. This ensures that if a non-numeric organization_id is provided, it's treated as a

Legal Boilerplate

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

Fixes SENTRY-5M2H