chore: remove released feature flag for extensions/ future state

[sarahetter]

🎉 Thanks for submitting a pull request! 🎉

Summary

Cleaning up feature flag now that it's been turned on for months now :)

---

For us to review and ship your PR efficiently, please perform the following steps:

• Open a bug/issue before writing your code 🧑‍💻. This ensures
  we can discuss the changes and get feedback from everyone that should be involved. If you`re fixing a typo or
  something that`s on fire 🔥 (e.g. incident related), you can skip this step.
• Read the contribution guidelines 📖. This ensures
  your code follows our style guide and passes our tests.
• Update or add tests (if any source code was changed or added) 🧪
• Update or add documentation (if features were changed or added) 📝
• Make sure the status checks below are successful ✅

A picture of a cute animal (not mandatory, but encouraged)

[github-actions]

This pull request adds or modifies JavaScript (.js, .cjs, .mjs) files.
Consider converting them to TypeScript.

[mrstork]

Is this for backwards compatibility? I was expecting us to fully switch over to the new endpoint without the feature flag, but is it the case that there might still something still calling this code without an account id once this code goes out?

[sarahetter]

Honestly this is just because I don't know if there would ever be a case where accountId isn't present. 😎 The config package has a few mysterious optional types on things like accountId where I'd anticipate them to always be present, but there's no comments around why they were marked as optional.

[mrstork]

That's fair enough. I was maybe being a little greedy thinking that we might even be able to get rid of the whole api endpoint for ${baseUrl}site/${siteId}/integrations/safe in the other system. No change needed here, I was just learning.

[lemusthelroy]

Looks good to me from the context I remember from when this logic was added previously.