docs: warn about using useRequestHeaders in useFetch

[danielroe]

🔗 Linked issue

resolves #23900

❓ Type of change

• 📖 Documentation (updates to the documentation, readme or JSdoc annotations)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

This updates documentation to avoid using useRequestHeaders in useFetch calls, following #23462.

We could also consider reverting that change.

Thoughts welcome. 🙏

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[nuxt-studio]

✅ Live Preview ready!

Name	Edit	Preview	Latest Commit
Nuxt Docs	Edit on Studio ↗︎	View Live Preview	235dc52

[manniL]

We could also consider reverting that change.

I think that'd be a bit better as it seems like a potential footgun 🤔
The problem is that this would be a breaking change, no?

Alternatively we should add an ESLint rule to disallow it somehow (if possible)

[webfansplz]

We could also consider reverting that change.

I agree that we should revert the changes. IMO, #23462 's case is even rarer than between the client and server have different request headers. For this case, we recommend that users add a key manually to avoid issues.

[danielroe]

I think that's reasonable. Let's go ahead and revert adding headers to the auto-generated key. PR welcome 🙏