Better communicate our limits in Core API errors

Currently, whenever a user hits a limit or gate of some sort, they are usually presented with a generic 400/403 response with little guidance on where to go next.
The CLI uses heuristics to make a best guess, but this approach is not very scalable. These should be removed as part of this issue.

We'd like to standardise these errors so API clients can better infer the context, and properly inform the users.

Flagsmith has two kinds of limits:
- Paywall/plan gates. These should respond with [402 Payment Required](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/402), contain `"code": "invalid-plan"`, and direct to https://www.flagsmith.com/pricing in the human-readable description.
- System limits, adjustable by support on demand. These should respond with a 400, contain `"code": "system-limit"`, and descriptions should direct to https://docs.flagsmith.com/support#getting-in-touch.

Acceptance Criteria:

- [ ] The FE dashboard is tested for all new error responses and handles it accordingly
- [ ] The code in the CLI which makes a best guess based on the existing 400/403 errors is removed
- [ ] All existing responses related to system limits are moved to 400s with relevant context in the error message
- [ ] All existing responses related to plan limits are moved to 402s with relevant context in the error message

Start by tracing the existing Core API 400/403 responses for plan and system limits, then inspect the CLI heuristics that infer their meaning. Check the FE dashboard tests and handling for each new response; done means the stated status codes, error codes, descriptions, and links are covered, CLI guessing is removed, and existing limit responses are classified correctly.

Written by the indexing model from the issue text.