(feat):Implement hub configuration validation

[qwasimintah]

Description

Implements a three-level hub configuration validation system with error/warning categorization. Validates hub schemas, profile-source references, and URL accessibility through VS Code commands, CLI script, and GitHub Actions workflow.

Type of Change

• 🐛 Bug fix (non-breaking change which fixes an issue)
• ✨ New feature (non-breaking change which adds functionality)
• 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
• 📝 Documentation update
• ♻️ Code refactoring (no functional changes)
• ⚡ Performance improvement
• 🧪 Test coverage improvement
• 🔧 Configuration/build changes

Related Issues

Closes #
Fixes #
Relates to #

Changes Made

• Added UrlValidator.ts service for checking URL accessibility with smart error/warning distinction (404/DNS = error, 401/403 = warning)
• Created ValidateHubCommand.ts for orchestrating three-level validation in VS Code
• Enhanced SchemaValidator.ts with validateHub() method and generateHubWarnings() for best-practice checks
• Added CLI script (templates/validate-hub.js) for CI/CD integration
• Created GitHub Actions workflow (templates/validate-hub.workflow.yml) for automated validation

Testing

Test Coverage

• Unit tests added/updated
• Integration tests added/updated
• Manual testing completed
• All existing tests pass

Manual Testing Steps

Tested On

• macOS

• Windows

• Linux

• VS Code Stable

• VS Code Insiders

Screenshots

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings or errors
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published

Documentation

• README.md updated
• JSDoc comments added/updated
• No documentation changes needed

Additional Notes

Reviewer Guidelines

Please pay special attention to:

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache License 2.0.

[wherka-ama]

@qwasimintah : a little comment on the extension vs CI validation

1. Validating everything from the user perspective(using the extension commands and/or scripts) makes total sense - we are putting ourselves in the shoes of the enduser and we test if all the resources are valid syntactically as well if we have the right acces to them. However, there is one aspect we need to take into account here - sources may come from private repositories which we might have access to, but that cannot be guaranteed for other users.

• ensure that the repositories behind the sources are always INTERNAL to ensure uniform access across the entire enterprise - this should be part of the checklist we always trigger during standard validation process

2. Validation in CI is very important, but the environment we use theredoes not reflect the one of the end user very well. The GITHUB_TOKEN generated for the workflow comes with explicit permissions which do not cross the boundary of a single organisation.

• ensure that for CI validation we use the GitHub App with minimal, yet uniform access to all INTERNAL repos in scope