docs: code smells/routing add

[Gaic4o]

Background

This PR adds a new Routing documentation page for Feature-Sliced Design. It clarifies that routing/redirect decisions should live in the app and pages layers, while lower layers communicate behavior via callbacks and remain unaware of concrete path strings. The examples were refined based on prior Telegram discussion history to reflect real-world usage.

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
pr-fsd	✅ Ready (View Log)	Visit Preview	512723c

[illright]

Thanks for pushing this! The article feels very well-written, though I don't agree with some of its suggestions.

• https://gaic4o-routing.pr-fsd.pages.dev/docs/guides/issues/routes#pages-layer
  Let's avoid giving examples of the login form being placed on the Features layer — I don't think it's an abstraction worthy of being separated onto another layer, and people are already having trouble internalizing FSD 2.1 as it is :)
• https://gaic4o-routing.pr-fsd.pages.dev/docs/guides/issues/routes#widgets-layer
  I feel like it's quite excessive to expose every link as a callback, to say nothing of semantic HTML. Links should be <a> tags, and these tags require a meaningful href. This guideline will get in the way of that.
• https://gaic4o-routing.pr-fsd.pages.dev/docs/guides/issues/routes#features-layer
  The same point from Widgets applies to features, but this time it's the same feeling of existential crisis I felt before. I almost feel like we should suggest that maybe there shouldn't be UI in features. Not quite ready to commit to it yet though :)
• https://gaic4o-routing.pr-fsd.pages.dev/docs/guides/issues/routes#shared-layer
  Regarding the abstraction around the router library, I would suggest to emphasize the YAGNI principle — "you ain't gonna need it" :D Basically, tell readers that this should not be done preemptively and that it doesn't make the architecture of the app better, quite the opposite, it makes it more complex, so this complexity better be justified by some requirement imposed externally on the dev team.
• https://gaic4o-routing.pr-fsd.pages.dev/docs/guides/issues/routes#domain-logic-vs-ui-flow
  While I would agree with this in abstract, personally I don't see myself ever following this principle. If the app I'm building is so complex that this principle is worth it for me, I see the complexity of the app as itself a big problem to be solved

Overall, I think there's a big slice of projects that aren't going to benefit from most of these rules except for, perhaps, separating route constants into a centralized object. If you agree, I would suggest to structure the article into two parts, the basic one, including just the route constants, and then the more complicated/decoupled approach, along with the reasons not to do it.

I also think that this article fits better in the Guides > Examples section, however poorly named that section is. It's less about "examples" and more about "practical problems in frontend". I wouldn't call routing a code smell or issue :p

One more thing that I think we could cover with this article — routing as a responsibility of the state manager. In the Russian-speaking community there are two state managers that are well-known — Effector and Reatom. Both of them offer plugins that let the state manager take control of routing, which is quite well integrated into its ecosystem.