fix(tracing): send addStackToTracingNoReply on the LocalUtils connection

[monkey (Develop-KIM)]

Summary

• Connection.internalSendMessage addressed addStackToTracingNoReply to localUtils.guid but sent it over its own transport. For a browser from connect() that transport is the server pipe, not the driver connection that owns LocalUtils, so the stack session opened by tracingStarted never received anything and setSources(true) produced no sources.
• Sends it on localUtils.connection instead, matching this._localUtils?.addStackToTracingNoReply(...) in packages/playwright-core/src/client/connection.ts. For a local connection that is the same object, so nothing changes there.
• TestBrowserTypeConnect#shouldRecordTraceWithSources already covered this and fails on main (0 sources instead of 1); it passes with the change. It never ran on CI because the sources job filters on -D test=*TestTracing*.

Fixes #1962

[Yury Semikhatsky (yury-s)]

Do you mind adding a test?

[monkey (Develop-KIM)]

Added a test: TestTracingOverConnect connects to a launch-server browser and traces with setSources(true). It passes the source root through Playwright.CreateOptions instead of reading PLAYWRIGHT_JAVA_SRC from the environment, so it runs in the regular test job, not only the *TestTracing* sources one. Without the fix it gets 0 sources instead of 1.

[monkey (Develop-KIM)]

The CI failure came from main rolling the driver to 1.63 (#1972) after this branch was cut: the trace zip now stores sources as src/<sha1>.java instead of resources/src@<sha1>.txt, so the .txt filter in the new test found nothing. Switched it to the startsWith("src/") check that TestJavaSourceLocationInConstructor got in that roll, and gave shouldRecordTraceWithSources in TestBrowserTypeConnect the same update since it had the same filter.