Fix vacuous-pass assertion in collection.config schema/EF conflict test

[Nimra3261]

"it should error if both schema and embedding function are provided" wrapped its assertion inside the catch block with no fallback:

try {
  const collection = await client.createCollection({ ... });
} catch (error) {
  expect(error).toBeDefined();
}

If createCollection() didn't throw, the catch body (and its expect(error).toBeDefined() check) never ran, and the test passed silently without ever exercising the assertion.

Rewritten as await expect(...).rejects.toBeDefined(), matching the pattern applied in #7508/#7509/#7525.

Flagged by review on #7525 pointing out this same shape recurs in a few places - this is the one instance not already covered by an open PR.

Addresses #2801

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readability, Modularity, Intuitiveness)