feat(network): add query factory library

[juanchoperezj]

What does this do?

Introduces a new approach to handle the query keys of the react-query.
We can now centralize and have a standardized way to declare our query keys, and from that place reuse them without worrying about typos.

Also, new things were added:

• Login endpoint
• Token usage in interceptors
• Carts query

Why did you do this?

Previously, we did not have a a consensus or an agreed approach in the community to handle query keys, causing different approaches to appear; using strings only for keys, enums, and others.
Sometimes this causes duplication, typos, or different query keys with the same data.

Who/what does this impact?

Impact the way the query keys are defined.

How did you test this?

Tests updated to match the UI.

[github-actions]

💯 Test Coverage

Lines	Statements	Branches	Functions
	46.64% (264/566)	43.1% (100/232)	33.02% (72/218)

😎 Tests Results

Tests	Skipped	Failures	Errors	Time
66	0 💤	0 ❌	0 🔥	27.353s ⏱️

👀 Tests Details • (46%)

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
All files	46.64	43.1	33.02	46.95
api	0	100	0	0
query-factory.ts	0	100	0	0	11–28
api/auth	0	100	0	0
use-login.ts	0	100	0	0	20–36
api/carts	0	0	0	0
query-keys.ts	0	100	0	0	3–5
types.ts	0	0	0	0
use-carts.ts	0	0	0	0	11–34
api/common	81.63	50	62.5	84.78
interceptors.ts	90.9	75	100	90.9	15
api/posts	0	100	0	0
index.ts	0	0	0	0
types.ts	0	0	0	0
use-add-post.ts	0	100	0	0	10–19
use-post-comments.ts	0	100	0	0	16–23
use-post.ts	0	100	0	0	12–17
use-posts.ts	0	100	0	0	12–15
app	0	0	0	0
login.tsx	0	100	0	0	11–24
app/(app)	0	0	0	0
_layout.tsx	0	0	0	0	15–78
carts.tsx	0	0	0	0	10–23
index.tsx	0	0	0	0	10–30
app/feed	0	0	0	0
[id].tsx	0	0	0	0	8–60
add-post.tsx	0	100	0	0	12–47
components	42.5	100	41.17	42.5
login-form.tsx	100	100	50	100
components/cart-item	0	0	0	0
cart-item.tsx	0	0	0	0	6–51

[fernandatoledo]

Let us know if you need help with the tests :D

[fernandatoledo]

This PR introduces multiple functionalities: new API hooks, types, query keys, and interceptors. For future PRs, it might be better to split into smaller, more focused PRs for easier review and faster feedback cycles.