feat(services): add general settings

[RemiBonnet]

Summary

I introduced a new library: @qovery/domains/service-settings/feature:

• centralize service settings UI/composition in a dedicated domain
• keep @qovery/domains/services/feature focused on shared service logic/hooks/payload builders
• reduce coupling and file size in the existing services feature
• remove the deprecated @pages associated to the general settings service

Routing integration:

• apps/console-v5/.../settings/route.tsx -> ServiceSettingsLayout
• apps/console-v5/.../settings/general.tsx -> ServiceGeneralSettings
• apps/console-v5/.../settings/danger-zone.tsx -> ServiceDangerZoneSettings

service-settings/
└── feature/
    └── src/
        └── lib/
            ├── service-danger-zone-settings/
            ├── service-general-settings/
            │   ├── application-general-settings/
            │   │   ├── application-general-settings.spec.tsx
            │   │   └── application-general-settings.tsx
            │   ├── container-general-settings/
            │   ├── database-general-settings/
            │   ├── helm-general-settings/
            │   ├── job-general-settings/
            │   ├── terraform-general-settings/
            │   └── service-general-settings.tsx
            └── service-settings-layout/

Let me know wdyt!

Screenshots / Recordings

https://www.loom.com/share/2c4077f28e6645fcbc8263fc316b1ddc

Testing

• Changes tested locally in the relevant Console's pages and Storybooks
• yarn test or yarn test -u (if you need to regenerate snapshots)
• yarn format
• yarn lint

PR Checklist

• I followed naming, styling, and TypeScript rules (see .cursor/rules)
• I performed a self-review (diff inspected, dead code removed)
• I titled the PR using Conventional Commits with a scope when possible (e.g. feat(service): add new Terraform service) - required for semantic-release
• I only kept necessary comments, written in English (watch for useless AI comments)
• I involved a designer to validate UI changes if I am not a designer
• I covered new business logic with tests (unit)
• I confirmed CI is green (Codecov red can be accepted)
• I reviewed and executed locally any AI-assisted code

[RemiBonnet]

Qovery can create a Preview Environment for this PR.
To trigger its creation, please post a comment with one of the following command.

Command	Blueprint environment
/qovery preview 15d69f24-9bc1-4a8d-80fe-d1bb1b2bcd00	New Navigation
/qovery preview {all|UUID1,UUID2,...}	To preview multiple environments

---

This comment has been generated from Qovery AI 🤖.
Below, a word from its wisdom :

Don’t Sacrifice Readability, you are going to debug it in 6 months

[codecov]

Codecov Report

❌ Patch coverage is 18.69159% with 261 lines in your changes missing coverage. Please review.
✅ Project coverage is 43.89%. Comparing base (4ee0caf) to head (9bef030).
⚠️ Report is 6 commits behind head on new-navigation.

Files with missing lines	Patch %	Lines
...eral-settings/service-general-settings-payloads.ts	6.94%	67 Missing ⚠️
...ervice-settings-layout/service-settings-layout.tsx	0.00%	43 Missing ⚠️
...vice-general-settings/service-general-settings.tsx	0.00%	40 Missing ⚠️
...general-settings/service-general-default-values.ts	0.00%	36 Missing ⚠️
.../feature/src/lib/source-setting/source-setting.tsx	42.85%	12 Missing and 4 partials ⚠️
...ervice-general-settings/service-general-payload.ts	0.00%	16 Missing ⚠️
...ger-zone-settings/service-danger-zone-settings.tsx	0.00%	13 Missing ⚠️
...ings/job-general-settings/job-general-settings.tsx	51.85%	7 Missing and 6 partials ⚠️
...ase-general-settings/database-general-settings.tsx	57.14%	3 Missing and 6 partials ⚠️
...configurations/use-list-database-configurations.ts	0.00%	2 Missing ⚠️
... and 5 more

Additional details and impacted files

@@                Coverage Diff                 @@
##           new-navigation    #2454      +/-   ##
==================================================
- Coverage           44.07%   43.89%   -0.19%     
==================================================
  Files                1045      562     -483     
  Lines               20320    12572    -7748     
  Branches             5887     3624    -2263     
==================================================
- Hits                 8957     5519    -3438     
+ Misses               9753     6128    -3625     
+ Partials             1610      925     -685     

Flag	Coverage Δ
unittests	43.89% <18.69%> (-0.19%)	⬇️

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

☔ View full report in Codecov by Sentry.
📢 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.

[rmnbrd]

In my opinion we should avoid prop drilling, especially while creating new components, it is a good opportunity to get rid of the ones that can be retrieved using hooks.

[rmnbrd]

This test file is gone, right?

[RemiBonnet]

This is from the pages library that we are currently removing

[rmnbrd]

Here too, could we get rid of these props?

[RemiBonnet]

We could get rid of organization if you want to remove this prop. But for service, I think it's a good thing to keep it because I would like to return only the Application type. This way, the component knows only this type and not others, which avoids having to cast inside it

For organization, I don't have strong concerns, but in my mind it could avoid calling the hook inside the component and prevent potential circular dependencies. Let me know what you prefer!