removing user hint when refreshing models

[requesty-JohnCosta27]

Description

Previously we showed a hint to the user to go back to the home screen (which would trigger a refetch of /models in a previous Roo version). But now the button alone works, so no need for this warning

Test Procedure

1. Select Requesty as a provider
2. Check models list
3. Create a new policy on the Requesty UI
4. Click the models refresh button in Roo
5. Check that the new policy appears.

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes (if applicable).
• Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

Previously

Now

Screen.Recording.2025-09-05.at.17.13.40.mov

[roomote]

Thank you for this clean and focused PR! The removal of the unnecessary hint message improves the user experience by eliminating confusion. The refresh button now works directly without requiring users to navigate away and back.

The code changes are minimal and well-executed - removing the state management complexity while maintaining functionality.

[roomote]

Nice cleanup! Removing this state variable simplifies the component.

One minor suggestion for completeness: The translation key is now unused across the codebase. While not critical, it would be good housekeeping to remove this unused translation from all locale files (en, fr, de, etc.) to keep them clean. You could do this in a follow-up PR if you prefer.

[requesty-JohnCosta27]

Can you remove it?

[daniel-lxs]

Nice addition with the animated refresh button! Just a heads up - there's a potential memory leak with the timeout in AnimatedRefreshButton. The timeout should be cleared when the component unmounts to prevent issues if the user navigates away while the animation is active. A simple useEffect cleanup function would handle this.

Let me know if you have any questions!

[requesty-JohnCosta27]

Nice addition with the animated refresh button! Just a heads up - there's a potential memory leak with the timeout in AnimatedRefreshButton. The timeout should be cleared when the component unmounts to prevent issues if the user navigates away while the animation is active. A simple useEffect cleanup function would handle this.

Let me know if you have any questions!

Ah of course! You're right. I ammended the commit.

[requesty-JohnCosta27]

@daniel-lxs do you mind taking another look please?

[daniel-lxs]

While removing the unnecessary hint message is great, I'm wondering if the new AnimatedRefreshButton component might be adding unnecessary complexity? The component introduces:

• A new abstraction with its own state management
• A timeout that needs cleanup (though properly handled)
• A hardcoded border-green-500 color that doesn't follow VSCode theme variables

Could we consider simplifying this to just use the standard Button without animation? The refresh feedback is already provided by the updated model list itself. If visual feedback is needed, perhaps a loading state or disabled state during the refresh operation would be more aligned with existing UI patterns?

[requesty-JohnCosta27]

While removing the unnecessary hint message is great, I'm wondering if the new AnimatedRefreshButton component might be adding unnecessary complexity? The component introduces:

• A new abstraction with its own state management
• A timeout that needs cleanup (though properly handled)
• A hardcoded border-green-500 color that doesn't follow VSCode theme variables

Could we consider simplifying this to just use the standard Button without animation? The refresh feedback is already provided by the updated model list itself. If visual feedback is needed, perhaps a loading state or disabled state during the refresh operation would be more aligned with existing UI patterns?

Yeah that is true. Good point.

I dropped the commit.

[requesty-JohnCosta27]

@daniel-lxs could you take another look please?

[daniel-lxs]

Thank you @requesty-JohnCosta27