Allow admin to force team type change

[knolleary]

Follow up to #8456

This allows an admin to change team type of an manual billing team even if the team usage exceeds the new team type usage limits. A warning is shown to the admin making the change in this scenario - telling them to apply the necessary limit overrides after making the team type change.

The second commit fixes the handling of a 0 device limit in the frontend. That was interpreted to mean 'unlimited' - whereas the backend uses -1 to mean unlimited. With the new Hub plan, a limit of 0 is valid but wasn't being honoured in the UI.

With this fix it now shows the team limit banner on the Remote instance page, and disables the 'add instance' button on the team home page if the limit has been reached.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.88%. Comparing base (2c0e87d) to head (5f55174).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8471      +/-   ##
==========================================
+ Coverage   76.77%   76.88%   +0.10%     
==========================================
  Files         460      460              
  Lines       24703    24745      +42     
  Branches     6573     6598      +25     
==========================================
+ Hits        18966    19024      +58     
+ Misses       5737     5721      -16     

Flag	Coverage Δ
backend	76.88% <100.00%> (+0.10%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[hardillb]

Logically looks good, I don't have enough local billing stuff setup to test the all the UI tweaks (should really find time to set it all up again)

[cstns]

The new teamDeviceLimitReached gate on the Home page reads totalDevices, which is summed from deviceStateCounts. That count comes from GET /teams/:teamId/instance-counts, and it has a few problems as a source for a limit check:

1. It's RBAC-filtered per user (Device.countByState skips devices in applications the user lacks device:read on). A user with restricted per-application roles sees an undercount, so their Add Instance button stays enabled on a team that's actually at its limit, and the create then fails server-side with device_limit_reached. That's the exact flow this PR is trying to get rid of.

2. It's fetched async in mounted() and not awaited, so the gate treats the count as 0 on first render. And since getDeviceStateCounts() ends with .catch(e => e), a failed fetch leaves it at 0 permanently, so the gate never engages for that visit.

3. It's never refreshed after creating a device. deviceCreated() only opens the credentials dialog, so a team one below its limit can create a device and the button stays enabled until a reload (instance deletion on this page does re-fetch, so the create path looks like an oversight).

The same undercount also flows into RecentlyModifiedDevices via the totalDevices prop and into TeamDeviceCreateDialog as teamDeviceCount.

Might be worth having the gate read team.deviceCount instead, which is the authoritative count the other copies of this computed already use (DevicesBrowser.vue, DeviceStep.vue), and adding a re-fetch (or team refresh) in deviceCreated(). That would cover all three points, and deviceStateCounts can stay for the state breakdown widgets it was built for.

[cstns]

see comment above