Document rationale against generic CRUD/service pattern

Added detailed comments in CatalogService and ICatalogService explaining why a generic CRUD base service or repository is not suitable for this solution, due to entity-specific domain logic and stored procedure usage. Removed the previous Copilot comment from CatalogRepository. No functional changes; updates are for architectural clarity.

DbFirst.Application/Catalogs/CatalogService.cs

@@ -5,6 +5,22 @@ using DbFirst.Domain.Entities;
 namespace DbFirst.Application.Catalogs;
 
 //TODO: create generic service to reduce code duplication
+
+/* Copilot's Response:
+A generic CRUD base service adds little value in your case:
+
+Pros:
+• Less boilerplate for simple entities without special logic.
+• Uniform CRUD signatures.
+
+Cons/Practical here:
+• Domain logic differs per entity(unique title check, setting audit fields, forbidding title changes, stored procs with output GUID).
+• Generic services tend to be diluted by virtual methods/hooks for special cases—ending up with per-entity overrides and little real gain.
+• With stored procedures and output parameters, the pattern doesn’t fit cleanly because operations aren’t symmetric (separate procs for insert/update/delete).
+
+Conclusion: For this solution a generic service would be more overhead than benefit. If you later have multiple very similar entities without special logic,
+you could consider a lightweight generic interface/base; for now, the specialized service implementation is cleaner. */
+
 //TODO: implement CQRS pattern with MediatR
 public class CatalogService : ICatalogService
 {