(test) Removed convertRegistry from e2e test infra that implicitly converts DDS registries

[agarwal-navin]

Description

The convertRegistry function in the test infra that replaces DDS registries passed in by tests with a versioned one as per the compat version the test is running in. For example, if the test is running in layer compat version mode where DataStore version is 1.4.0, it replaces the registry with its 1.4.0 version.
This works in most cases but has a few shortcomings:

1. If a test creates a custom DDS registry (say a tree registry via configuredSharedTree), this is replaced with the base registry losing all the custom configurations.
2. This happens explicitly and the test authors may not know about this. This can lead to unintended consequences where the DDS is versioned but the other objects like container runtime, data store, loader, etc. may not be. The tests can fail with seemingly unrelated and random errors.

This change fixes some of the above problems by doing the following:

• Removed the convertRegistry function.
• Updated almost all tests to use the correct version of the APIs exposed by describeCompat. There are a few tests which still use the latest APIs - added comments / tagged task items for them.
• There is a lint rule that notify test authors if they don't use the compat APIs. It was not working for all cases. Updated it to work for all knowns cases.
• Added documentation on the correct pattern to use for various scenarios. Also, pointed the lint rule error message to this document.

Future work

The test infra still implcitily uses compat versions of other objects - driver, loader, runtime, data store, DDS, etc. when tests don't create these objects explicitly. But these don't happen for all patterns - for example, a test can create a loader of a particular version and use it to create different versions of container runtimes and other objects leading to an unexpected mismatch.
One approach to fix this is to have APIs that explicitly tell the test which API is being used - old / new, for create / load, etc. That combined with the lint rules should make it clearer and more intuitive to test authors when they use incorrect APIs or incorrect version combinations of objects.

[github-actions]

Hi! Thank you for opening this PR. Want me to review it?

Based on the diff (1592 lines, 65 files), I've queued these reviewers:

• Correctness — logic errors, race conditions, lifecycle issues
• Security — vulnerabilities, secret exposure, injection
• API Compatibility — breaking changes, release tags, type design
• Performance — algorithmic regressions, memory leaks
• Testing — coverage gaps, hollow tests

How this works

• Adjust the reviewer set by ticking/unticking boxes above. Reviewer toggles alone don't trigger anything.

• Tick Start review below to dispatch the review fleet.

• After review finishes, tick Start review again to request another run — it auto-resets after each dispatch.

• This comment updates as new commits land; your reviewer selections are preserved.

• Start review

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> fluid-framework-docs-site@0.0.0 ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> fluid-framework-docs-site@0.0.0 serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> fluid-framework-docs-site@0.0.0 check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

Stats:
  288859 links
    1925 destination URLs
    2175 URLs ignored
       0 warnings
       0 errors

[github-actions]

Fleet Review — In progress

Running reviewers: correctness, security, api-compatibility, performance, testing

View run