Refactor Scrapper controllers to use application use cases #7

Problem

Scrapper controllers directly depend on repository interfaces and coordinate business operations themselves.

For example, LinksController checks whether a chat exists, loads data from the repository, and decides whether an operation is a conflict:

• LinksController
• TgChatController
• TagsController

This couples the HTTP layer to persistence and places application logic in controllers.

Proposed solution

Introduce application use cases for link, chat, and tag operations:

• AddLinkUseCase
• RemoveLinkUseCase
• GetLinksUseCase
• RegisterChatUseCase
• DeleteChatUseCase
• tag CRUD use cases

Use cases should return explicit results such as:

• Success
• ChatNotFound
• AlreadyExists
• UnsupportedUrl

Controllers should only:

1. Read HTTP input.
2. Execute a use case.
3. Map its result to an HTTP response.

Acceptance criteria

• Scrapper controllers do not depend on repository interfaces.
• Business decisions are implemented in application use cases.
• ChatExists is not called separately before link operations.
• Use cases distinguish missing chats from duplicate subscriptions.
• Current HTTP API remains backward compatible.
• Unit tests cover each use case result.