fix(deps): replace @opentelemetry/sdk-trace-web with @opentelemetry/sdk-trace

[overbalance]

What problem is this solving?

At OpenTelemetry 2.9.0, @opentelemetry/sdk-trace is the new core trace package that will replace sdk-trace-base (open-telemetry/opentelemetry-js#6775), and the span-processor constructors moved to a single options object: BatchSpanProcessor (#6817) and SimpleSpanProcessor (#6504). @opentelemetry/sdk-trace-web re-exports the base types through a compat shim that keeps the old positional signature. The SDK was pulling its base types and processors through the web package, which left it on the shimmed path and on the positional constructor form.

Short description of the changes

• Import base trace types and processors (ReadableSpan, SpanProcessor, SpanExporter, BatchSpanProcessor, SimpleSpanProcessor, ConsoleSpanExporter, InMemorySpanExporter, TracerProvider) from @opentelemetry/sdk-trace instead of @opentelemetry/sdk-trace-web, across SDK source, tests, demo, README, and the integration platforms. sdk-trace-web is kept only for the genuinely web-specific WebTracerProvider, StackContextManager, and DocumentLoad performance utilities.
• Use the object-form processor constructor at every call site (new BatchSpanProcessor({ exporter }), new SimpleSpanProcessor({ exporter })).
• Add @opentelemetry/sdk-trace as a direct dependency, drop the now-unused @opentelemetry/web-common, remove @opentelemetry/sdk-trace-web from each integration platform's dependencies, and regenerate THIRD_PARTY_NOTICES.txt.
• Consolidate the demo frontend tsconfigs into a single non-caching project, and add non-caching check (tsc) scripts to the integration and performance test workspaces, so their typechecks are no longer masked by stale build-mode caches.
• Document the EmbraceSessionPartBatchedSpanProcessor reliance on the unstable internal._export API.

How was this tested?

• npm run check (typecheck + eslint) passes across all workspaces.
• npm run build succeeds; attw reports no type problems.
• Trace unit tests pass (EmbraceTraceManager, EmbraceSessionPartLifecycle, EmbraceTraceExporter).

Checklist

• I have performed a self-review of my code
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[github-actions]

Chrome DevTools Protocol Tracing (Script: 134.25ms, Heap: 13.82MB)

	Number of Requests	Size of Requests	Script Duration	Task Duration	Heap Used Size
Requests	+13 requests	+41.71 KB
Page Loaded			+23.32 ms	+16.73 ms	+1.17 MB
Generate 100 fetch requests			+23.89 ms	+96.87 ms	+1.66 MB
Generate 100 XHR requests			+43.11 ms	+109.32 ms	+2.78 MB
Click 100 buttons and generate 100 logs			+33.68 ms	+70.86 ms	+2.47 MB
Throw a 100 exceptions			-0.29 ms	+36.79 ms	+2.41 MB
End Session			+10.53 ms	+41.26 ms	+3.33 MB
Total	+13 requests	+41.71 KB	+134.25 ms	+371.83 ms	+13.82 MB

Lighthouse (Script Eval: 134.23ms)

	Difference	Description
Total Blocking Time	+6 ms	Difference in Total Blocking Time: Sum of all time periods between FCP and Time to Interactive, when task length exceeded 50ms, expressed in milliseconds. Learn more about the Total Blocking Time metric.
Main Thread Time	+108.30 ms	Difference in Main Thread Time: Consider reducing the time spent parsing, compiling and executing JS. You may find delivering smaller JS payloads helps with this. Learn how to minimize main-thread work
Script Evaluation Time	+134.23 ms	Difference in Script Evaluation Time: Consider reducing the time spent parsing, compiling, and executing JS. You may find delivering smaller JS payloads helps with this. Learn how to reduce Javascript execution time.

Platform Tests (vite-7 es2015 gzip: 70.28KB)

vite-6 Platform Tests

	Total Uncompressed Size	Total Gzip Size
vite-6 - es2015	+205.54 KB	+70.33 KB

vite-7 Platform Tests

	Total Uncompressed Size	Total Gzip Size
vite-7 - es2015	+205.54 KB	+70.28 KB

webpack-5 Platform Tests

	Total Uncompressed Size	Total Gzip Size
webpack-5 - es2015	0 KB	0 KB

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.70%. Comparing base (6a578eb) to head (971fb38).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1428      +/-   ##
==========================================
+ Coverage   96.69%   96.70%   +0.01%     
==========================================
  Files         234      234              
  Lines       10079    10080       +1     
  Branches     1414     1415       +1     
==========================================
+ Hits         9746     9748       +2     
+ Misses        331      330       -1     
  Partials        2        2              

Files with missing lines	Coverage Δ
...ers/EmbraceTraceExporter/OTLPFetchTraceExporter.ts	100.00% <100.00%> (ø)
...anagers/EmbraceLimitManager/EmbraceLimitManager.ts	99.58% <100.00%> (ø)
...ssors/BrowserSpanProcessor/BrowserSpanProcessor.ts	100.00% <100.00%> (ø)
...etworkSpanProcessor/EmbraceNetworkSpanProcessor.ts	96.77% <100.00%> (ø)
...rc/processors/EmbraceNetworkSpanProcessor/types.ts	100.00% <100.00%> (ø)
...rocessor/EmbraceSessionPartBatchedSpanProcessor.ts	90.14% <100.00%> (+0.06%)	⬆️
.../processors/PageSpanProcessor/PageSpanProcessor.ts	100.00% <100.00%> (ø)
...rocessors/SpanScrubProcessor/SpanScrubProcessor.ts	93.93% <100.00%> (ø)
.../processors/UserSpanProcessor/UserSpanProcessor.ts	94.59% <100.00%> (ø)
packages/web-sdk/src/sdk/initSDK.ts	98.67% <100.00%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.