fix: ensure source form follows URLPattern logic

[LuizFNJ]

Description

A fix was previously implemented to prevent URLs ending with a dot (.) in the ClaimReview form, but this was missing in the Source creation form. We already have a validation system for this within dynamicForm:

...(isURLField && {
    validURL: (v) =>
        !v ||
        URL_PATTERN.test(v) ||
        "sourceForm:errorMessageValidURL",
}),

However, this validation was not active in the Source form. I have enabled it to ensure the Source creation follows the defined URL_PATTERN.

Here you can see that we need to remove the dot before submitting the source:

Screen.Recording.2026-02-05.at.00.41.51.mov

Related Ticket #2161

Type of change

• Existing feature enhancement (non-breaking change which modifies existing functionality)

Testing

1. Access the page for adding a new source.
2. In the "Source URL" field, enter a link that ends with a period (Example: https://www.example.com/news.).
3. It should not be possible to add the source.
4. You should see a feedback message stating that the URL is invalid.

Developer Checklist

General

• Code is appropriately commented, particularly in hard-to-understand areas
• Repository documentation has been updated (Readme.md) with additional steps required for a local environment setup.
• No console.log or related logging is added.
• No code is repeated/duplicated in violation of DRY. The exception to this is for new (MVP/Prototype) functionality where the abstraction layer may not be clear (comments should be added to explain the violation of DRY in these scenarios).
• Documented with TSDoc all library and controller new functions

Frontend Changes

• No new styling is added through CSS files (Unless it's a bugfix/hotfix)
• All types are added correctly

Backend Changes

• All endpoints are appropriately secured with Middleware authentication
• All new endpoints have a interface schema defined

Tests

• All existing unit and end to end tests pass across all services
• Unit and end to end tests have been added to ensure backend APIs behave as expected

Test IDs

• Include the test ID when adding new tasks or components.
• Check that test IDs are present in the modified components.

Merge Request Review Checklist

• An issue is linked to this PR and these changes meet the requirements outlined in the linked issue(s)
• High risk and core workflows have been tested and verified in a local environment.
• Enhancements or opportunities to improve performance, stability, security or code readability have been noted and documented in Project do Github issues if not being addressed.
• Any dependent changes have been merged and published in downstream modules
• Changes to multiple services can be deployed in parallel and independently. If not, changes should be broken out into separate merge requests and deployed in order.