ci: Add automated Docker build validation workflow

[AnzalKhan16]

Description

This PR introduces a dedicated GitHub Actions workflow (docker-validation.yml) to automatically verify that the project's Docker images build successfully after code changes.

The workflow triggers on every pull request and push to the default branch. It utilizes Docker Buildx and GitHub Actions caching to build both the backend and frontend Docker images using their respective Dockerfiles, ensuring that images compile without issues before changes are merged. This helps catch missing dependencies or invalid Dockerfile instructions early without actually pushing the images to a registry.

Related Issues

#2373

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

How Has This Been Tested?

This workflow has been tested by verifying the syntax and configuration in the GitHub Actions file. It confirms that paths to backend/Dockerfile and frontend/Dockerfile are correct. It utilizes the official docker/setup-buildx-action and docker/build-push-action plugins and is set up with push: false to ensure a safe dry-run build validation.

Checklist

• My code follows the code style of this project.
• I have performed a self-review of my own 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.

[utksh1]

Thank you for your interest in contributing to SecuScan.

This PR/issue is being closed for one of the following reasons:

• Duplicate functionality that already exists in the project
• Modifies critical workflows without prior maintainer discussion
• Assumes infrastructure or processes not aligned with the project

We appreciate well-thought-out contributions, but please:

1. Review existing CI/CD setup before proposing changes
2. Open an issue for discussion before submitting large PRs
3. Coordinate with maintainers on infrastructure changes

For the features we'd like to keep (Dependabot, SHA pinning, multi-arch builds, Scorecard), we'll review those PRs individually.