fix(guild): treat very high as high without phone verification (#3095)

fluxer_docs/src/content/docs/http-api/guilds.mdx

@@ -290,7 +290,7 @@ A verification level gates member participation. Fluxer evaluates it when a memb
 
 <sup>2</sup> The membership age requirement is skipped when the join timestamp cannot be read, so the level behaves as MEDIUM
 
-<sup>3</sup> A verified phone number is the whole requirement at this level
+<sup>3</sup> A verified phone number is the whole requirement at this level. A deployment whose [instance features](/http-api/instance/#instance-features-object) report `phone_verification_enabled` as false evaluates a stored VERY_HIGH as HIGH. [Modify guild](#modify-guild) then rejects a change to VERY_HIGH with 400 `INVALID_FORM_BODY` and the field code `VALUE_MUST_BE_INTEGER_IN_RANGE`, and a [guild template](#guild-creation-template-object) value is clamped to HIGH
 
 The guild owner, a bot, and any member holding at least one role bypass the check at every level.
 
@@ -674,7 +674,7 @@ Every field is optional. An omitted field preserves its current value, and a fie
 
 <sup>5</sup> The channel must exist in this guild and be a voice channel, and is otherwise rejected with `AFK_CHANNEL_MUST_BE_IN_GUILD` or `AFK_CHANNEL_MUST_BE_VOICE`
 
-<sup>6</sup> A guild with `DISCOVERABLE` cannot be lowered below LOW and is rejected with the field code `DISCOVERABLE_GUILD_VERIFICATION_LEVEL_TOO_LOW`
+<sup>6</sup> A guild with `DISCOVERABLE` cannot be lowered below LOW and is rejected with the field code `DISCOVERABLE_GUILD_VERIFICATION_LEVEL_TOO_LOW`. A change to VERY_HIGH is rejected with the field code `VALUE_MUST_BE_INTEGER_IN_RANGE` when phone verification is unavailable, as [Verification levels](#verification-levels) states
 
 <sup>7</sup> Sending the value the guild already holds needs neither ownership nor sudo mode, and an owner without a configured second factor is rejected with the field code `MUST_ENABLE_2FA_BEFORE_REQUIRING_FOR_MODS`
 

fluxer_docs/src/content/docs/http-api/instance.mdx

@@ -138,6 +138,7 @@ Deployment-wide switches a client reads before it offers a feature, plus whether
 | self_hosted | boolean | Whether this deployment identifies itself as self-hosted |
 | presigned_attachment_uploads | boolean | Whether a client can request presigned attachment upload URLs |
 | emails_enabled<sup>1</sup> | boolean | Whether the deployment sends email |
+| phone_verification_enabled<sup>5</sup> | boolean | Whether accounts can verify a phone number |
 
 <sup>1</sup> The value is true only when email is switched on and the transport is completely configured
 
@@ -147,6 +148,8 @@ Deployment-wide switches a client reads before it offers a feature, plus whether
 
 <sup>4</sup> On a hosted deployment, true while billing is switched on and a Stripe secret key is set. A self-hosted deployment reports true while a Stripe secret key is set and `premium_enabled` is true, even after billing is switched off
 
+<sup>5</sup> Defaults to true on a hosted deployment and false on a self-hosted one. While it is false, the `VERY_HIGH` [verification level](/http-api/guilds/#verification-levels) is evaluated as `HIGH`
+
 A deployment that reports `emails_enabled` as false sends no verification, password recovery, or IP authorisation message, and the flows that depend on one are unusable there. [Deployment availability](/http-api/deployment-availability/) states which routes a self-hosted deployment does not serve at all.
 
 ## GIF provider object

fluxer_docs/src/content/docs/http-api/users/phone-verification.mdx

@@ -17,7 +17,7 @@ Every route here needs a non-bot user session, and each one admits a session wit
 - The account already holds a verified phone.
 - A TOTP [authenticator](/http-api/users/#authenticator-types) is enrolled on the account.
 - The stored suspicious activity bitfield is non-zero.
-- The account belongs to at least one guild whose [verification level](/http-api/guilds/#verification-levels) is `VERY_HIGH`.
+- The account belongs to at least one guild whose [verification level](/http-api/guilds/#verification-levels) is `VERY_HIGH`, and the [instance features](/http-api/instance/#instance-features-object) report `phone_verification_enabled` as true.
 
 An account satisfying none of them is refused with 403 `PHONE_ADD_NOT_ELIGIBLE`.