Fix profile fields width by adding modifier support to BorderedTextField

[muhAzri]

Fix profile fields width by adding modifier support to BorderedTextField

Thank you for opening a Pull Request!
Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

• Make sure to open a GitHub issue as a bug/feature request before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests are added/updated (if necessary)
• Ensure the linter passes (./codeAnalysis to automatically apply formatting/linting)
• Appropriate docs were updated (if necessary)

Description

This PR fixes an issue where the profile fields in the ProfileScreen weren't filling the maximum width of the screen, leaving unused space on the right side. The root cause was that the BorderedTextField component didn't accept a modifier parameter, preventing it from receiving layout directives from its parent components.

Changes

• Added a modifier parameter to the BorderedTextField component
• Applied the modifier to the Box wrapper in BorderedTextField
• Updated ProfileField to pass Modifier.fillMaxWidth() to BorderedTextField
• Removed redundant padding application in BorderedTextField for cleaner code

Visual Changes

Before: Profile fields didn't utilize the full width of the screen, leaving empty space on the right

After: Profile fields now properly extend to fill the entire width of the screen

Fixes #1138 🦕

[EngrTaofeek]

@muhAzri thanks for this looks like great progress just one tiny detail left. The green underline does not extend to the end as shown I the screenshot below.

just that

[EngrTaofeek]

Hi @muhAzri ,

To ensure you have everything you need to run the application smoothly, I'd like to share the tree_tracker.keys.properties file with you. Please join the Greenstand Slack community, and I'll send it to you there. This will eliminate the need to comment/uncomment lines in your configuration.

Also, to keep our workflow organized, I recommend creating a new branch for each feature, task, or pull request (PR) instead of working directly on the master branch of your fork. This practice helps maintain a clean and manageable version history.

Thanks

[muhAzri]

Hi @EngrTaofeek
Thanks a lot for the feedback!

✅ I've fixed the reported issues the green underline not extending fully — it should now match the expected result.

🙏 Noted on the suggestion to use a separate branch for future PRs. I’ll definitely follow that practice going forward to keep things more organized.

Looking forward to your review!
Thanks

[EngrTaofeek]

Looks good. Thank you for your contribution I have merged it in.