Summary

This PR adds a regression test confirming that issue #7014 has been resolved in the 3.x codebase. The bug reported that when two different relation types share the same role name (like owner), querying by the unscoped role name would incorrectly reject the query as unsatisfiable. After a thorough investigation of the type inference pipeline, I've confirmed that the 3.x Rust rewrite handles this case correctly and the query is no longer rejected.

Background

The original issue described a scenario with two relation types that both declare a role called owner:

define
  person sub entity;
  pet sub entity;
  toy sub entity;
  pet-ownership sub relation, relates owner, relates pet;
  toy-ownership sub relation, relates owner, relates toy;
  person plays pet-ownership:owner;
  pet plays pet-ownership:pet, plays toy-ownership:owner;
  toy plays toy-ownership:toy;

The query match (owner: $x, pet: $y); (owner: $y, toy: $z); get; should return results where $x is a person, $y is a pet, and $z is a toy. In TypeDB 2.x, this query was incorrectly rejected because the type inference engine would alias the two occurrences of the owner role label into a single type variable.

Root Cause Analysis

In the 2.x Java implementation, role labels with the same name were mapped to the same type variable. The 3.x Rust rewrite fixed this through a redesign of the IR translation layer. The function register_type_role_name_var in ir/translation/constraints.rs now calls create_anonymous_variable() for every occurrence of a role label, ensuring each mention of owner gets its own independent variable. This means the type inference engine treats each role position independently, which is the correct behavior.

What Changed

Added a single regression test test_issue_7014_unscoped_role_name_not_aliased to compiler/annotation/type_seeder.rs. The test sets up the exact schema from the issue, constructs the IR for the reproducing query, runs type inference, and verifies that:

1. Type inference completes successfully without returning an error.
2. All three named variables receive non-empty type annotations.
3. The inferred types are correct: $x includes person, $y includes pet, and $z includes toy.

Closes #7014