Add similarity service to publish extension and namespace workflow

[janbro]

Add Similarity Service to Prevent Namesquatting

#1396

This PR introduces a similarity-checking service designed to detect and block extensions whose names are too close to existing ones.

Summary

• Uses PostgreSQL’s Levenshtein distance (via fuzzystrmatch) to evaluate similarity across extension names, namespaces, and display names.
• Supports a configurable threshold and verified-publisher rules (skip checks for verified publishers and/or compare only against verified extensions).
• Surfaces conflicts during publishing as errors when submitted values are too similar to existing extensions.

Technical Changes

• Added SimilarityService which supports searches that uses Levensthein distance queries to find similar extensions and namespaces.
• Added SimilarityConfig and SimilarityCheckService which is the policy enforcement layer that applies all configuration-based gates (enabled/disabled, threshold, exclusions, etc.). This is the single entry point for publishing workflows.
• Enabled fuzzystrmatch through a database migration.
• Integrated similarity checks into the repository layer using Jooq queries.
• Feature is disabled by default and must be explicitly enabled via configuration.

Design Considerations

• What about existing extensions:
  Similarity checks can be enabled to only run on extensions with no pre-existing version. This allows some flexibility for rollout to allow existing publishers to keep names/namespaces while a migration plan is coordinated.

• Same-publisher similarity exceptions:
  Extensions within namespaces that the publisher owns can be exempt through the configuration. Publishers often maintain multiple variants with intentionally similar names (e.g., language specific versions like redhat.vscode-extension-dmn-editor and redhat.vscode-extension-bpmn-editor) which are outside the threat model.

• Verified-publishers:
  Similarity checks for verified publishers can be toggled on or off. This reduces disruption for legitimate publishers during rollout. Once awareness increases, it can be tightened but would require coordination with verified publishers for migration of namespaces/names that are too similar.

• Using verified-only comparison sets:
  Limiting the comparison pool to verified extensions reduces false positives by prioritizing established publishers and improves performance by shrinking the candidate set for Levenshtein evaluation.

Example configuration

ovsx:
  similarity:
    enabled: true                 # Enable/disable the feature
    levenshtein-threshold: 0.2    # Min 20% name difference allowed
    skip-verified-publishers: true  # Skip checks for verified publishers
    check-against-verified-only: true # Compare only against verified extensions
    exclude-owner-namespaces: true # Skip checks against extensions in namespaces owned by the same publisher
    new-extensions-only: false # Skip checks for extension with existing versions, applies similarity checks only to new extensions

[netomi]

I will merge this into the target branch, please keep the original branch alive in case we need to do changes.

When finally merging the change to master, we will do it from the original branch afaict.