docs(ktextarea): to clarify maximum characters of ktextarea for readers

[Miltonbhowmick]

it gives hint of maximum characters for textarea by default.

Summary

This PR enhances the docs of KTextArea by adding a note of default maximum 2048 characters limit.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[netlify]

✅ Deploy Preview for kongponents-sandbox ready!

Name	Link
🔨 Latest commit	023bb9b
🔍 Latest deploy log	https://app.netlify.com/sites/kongponents-sandbox/deploys/671fd9700856300008ab29fe
😎 Deploy Preview	https://deploy-preview-2484--kongponents-sandbox.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[adamdehaven]

The limit is already documented in the characterLimit prop docs; is this sufficient? Or are you suggesting it needs to more prominent?

[Justineo]

Do you know why do we have this default limit? It seems to be uncommon so I think it’s reasonable to make it a little more prominent.

[adamdehaven]

IIRC it’s a limitation on some arbitrary endpoint we own or maybe our “normal” threshold. I don’t mind adding the extra note; we should just update this change to include a link to the corresponding prop in the note

[Justineo]

Maybe it’s better to remove this default limit in the future and make it injectable. Then we can provide meaningful defaults in our AppShell.

[Miltonbhowmick]

Thank you for the feedback, @adamdehaven and @Justineo.
I agree that making the character limit more prominent in the documentation could benefit users, especially since this limit might be unexpected. Even if it’s standard in this system or based on specific endpoint constraints, documenting it directly in the main description section (alongside the characterLimit prop link) would ensure users understand it early, without needing to search for details in the prop list.

Adding this information up front also helps make it clear that the default limit could be adjusted in the future, as discussed. This would set the stage for a more flexible limit if we later decide to make it configurable.