fix: match repodata records by file name

[puneetdixit200]

Description

Fixes #1721

fn constraints were parsed into MatchSpec, but were not checked when matching MatchSpec or NamelessMatchSpec against a RepoDataRecord. That allowed a path-style spec such as fn=file:///.../package.conda to behave like a name-only match instead of selecting by the record's archive filename.

This adds RepoDataRecord filename matching and treats URL/path fn values as their basename, so a local path dependency can match package-...conda while still rejecting a different archive filename.

How Has This Been Tested?

Red check before implementation:

• cargo test -p rattler_conda_types test_file_name_matches_repodata_identifier -- --nocapture failed because fn=other-1.0-py37_0.conda still matched the record.

Green checks after implementation:

• cargo test -p rattler_conda_types test_file_name_matches_repodata_identifier -- --nocapture
• cargo test -p rattler_conda_types --lib
• cargo fmt --all -- --check
• cargo clippy -p rattler_conda_types --all-targets -- -D warnings
• git diff --check

AI Disclosure

• This PR contains AI-generated content.
  • I have tested any AI-generated content in my PR.
  • I take responsibility for any AI-generated content in my PR.

Tools: OpenAI GPT-5.5 was used to inspect the matchspec/repodata matching path, add the regression test and implementation, and draft this PR text. The changes and tests were reviewed and run locally.

Checklist:

• I have performed a self-review of my own code
• I have added sufficient tests to cover my changes.

[baszalmstra]

is this also what conda does?

[puneetdixit200]

I checked conda's current MatchSpec/PackageRecord path. MatchSpec.match() iterates every match component and compares it against the same field on the package record, and fn is a PackageRecord field. When a record only has a URL, conda derives fn from Channel(url).package_filename; on the spec side, MatchSpec.fn normalizes fn/url through basename(...).

So yes, this is intended to match conda behavior: a spec like fn=file:///.../pkg.conda is compared as the archive filename, not treated as a name-only match.

Refs I checked:

• https://github.com/conda/conda/blob/3037a5b5b0cc58e0856c758f763a4cf804775927/conda/models/match_spec.py#L377-L401
• https://github.com/conda/conda/blob/3037a5b5b0cc58e0856c758f763a4cf804775927/conda/models/match_spec.py#L640-L647
• https://github.com/conda/conda/blob/3037a5b5b0cc58e0856c758f763a4cf804775927/conda/models/records.py#L177-L188

[puneetdixit200]

Addressed in the follow-up commits. The current implementation no longer parses a URL for fn matching; it strips query/fragment text and takes the basename with string slicing. I also added a comment documenting that this mirrors conda's MatchSpec.fn/PackageRecord.fn filename semantics.

[puneetdixit200]

Addressed the URL parsing concern in the current head: file_name_matches now strips query/fragment and takes the basename with string operations instead of calling Url::parse during matching. I also reran cargo test -p rattler_conda_types test_file_name_matches_repodata_identifier locally and it passes.