fix(bitbucket): fallback for missing notification URLs

[ShiroKSH]

Summary

• Use the repository URL when a Bitbucket notification has no entity or content URL.
• Cover the adapter fallback and shared notification URL generation with regressions.

Root cause

Bitbucket permits both notification URL fields to be null. That left the adapter with an empty default URL, which the shared URL builder tried to construct before it could apply a fallback.

Validation

• pnpm check
• pnpm test — 158 files, 1218 tests passed
• pnpm build

[setchy]

Hi @ShiroKSH - do you have an example response fragment from the Atlassian GraphQL API that you could share?

I'll also cross-reference how I'm handling this in https://github.com/setchy/atlassify/pulls - as from my experience I don't recall ever having a bitbucket notification that doesnt have a valid url. it could be that our gitify mapping utilities need some adjustment

[setchy]

In Atlassify, the Bitbucket URL should be mapped from headNotification.entity.url, which also where we extract the repository slug name from.

Atlassify does have a catch-all fallback to headNotification.url, but I don't think that's used for Bitbucket-based notifications

[ShiroKSH]

@setchy Thanks for checking. I do not have a captured production fragment; the test case is synthetic and based on the generated GraphQL type, where both content.url and content.entity are nullable. It represents a content object with url: null and entity: null.

The current transformer already accepts that combination in its existing missing-entity-URL test and produces the synthetic repository URL. This PR only prevents that accepted state from reaching new URL('').

I agree that nullability alone does not prove a live API response. If Atlassify confirms that a URL is guaranteed in production, I will revise or close this PR rather than preserve a fallback for an impossible state.

[setchy]

can't hurt to be extra defensive, though i haven't seen this in production