feat: add indicator of disabled check

[VikaCep]

Add UI hint for checks disabled due to free tier overage

Closes issue #1261

Summary

Implements a visual indicator for checks that have been disabled due to free tier overage. When the disableReason field is populated on a check object, users will now see a clear orange "Disabled" badge with a tooltip explaining the reason.

[github-actions]

Script size changes

Name	+/-	Main	This PR	Outcome
[module.js]	+0.03%	2,417.74 kB	2,418.42 kB	✅
[datasource/module.js]	=	24.34 kB	24.34 kB	✅

Totals

Name	+/-	Main	This PR	Outcome
[Scripts]	+0.03%	2,442.08 kB	2,442.76 kB	✅
[Non-script Assets]	=	2,589.66 kB	2,589.66 kB	✅
[All]	+0.01%	5,031.74 kB	5,032.42 kB	✅

Generated by 🚫 dangerJS against e109021

[ckbedwell]

@The-9880 -- I'm cross-referencing the OAS Check schema (also 👏) and I noticed disableReason is always present in the schema which then showed me that reasonless checks have an empty string. My preference would be null, would that be a big deal to change?

What are the current strings we have that this field can be?

I'd also like for us to agree that the reason field is some sort of enum we can map to. Reasons for this are:

1. i18n. The less English language strings we have coming from the API the easier it is for us to fully translate the app when we get round to it (which will be on the roadmap in FY27)
2. Depending on the reason we can change the UI and potential messaging. In particular if we wanted to try and upsell if someone's checks were disabled because they hit the free tier limit.

@VikaCep -- works great. Maybe just add a simple test that if disableReason is present it gets rendered in the UI and if it is an empty string it doesn't?

[The-9880]

@The-9880 -- I'm cross-referencing the OAS Check schema (also 👏) and I noticed disableReason is always present in the schema which then showed me that reasonless checks have an empty string. My preference would be null, would that be a big deal to change?

What are the current strings we have that this field can be?

I'd also like for us to agree that the reason field is some sort of enum we can map to. Reasons for this are:

1. i18n. The less English language strings we have coming from the API the easier it is for us to fully translate the app when we get round to it (which will be on the roadmap in FY27)
2. Depending on the reason we can change the UI and potential messaging. In particular if we wanted to try and upsell if someone's checks were disabled because they hit the free tier limit.

@VikaCep -- works great. Maybe just add a simple test that if disableReason is present it gets rendered in the UI and if it is an empty string it doesn't?

Hey! I can absolutely change this to be null-able - i.e. the field is not even returned if it is empty.

The current only value we are using for this is FREE_LIMIT_EXCEEDED, which is a string but formatted like an enum identifier. Does this work for the app?

[ckbedwell]

The current only value we are using for this is FREE_LIMIT_EXCEEDED, which is a string but formatted like an enum identifier. Does this work for the app?

Beautiful. Exactly what we want ❤️

@VikaCep can you make the changes so that we show a user-friendly message using something like a key/value map?

[VikaCep]

@VikaCep can you make the changes so that we show a user-friendly message using something like a key/value map?

For sure! Just pushed some updates :)

[ckbedwell]

LGTM!