Closes #26.

Problem

src/types/index.ts re-exported one type from the OpenTelemetry module:

export type { QueueInstrumentationConfig } from '../otel.js'

That pulled two optional peer dependencies into the generated barrel declaration:

// build/src/types/index.d.ts
import '@opentelemetry/api'
import '@opentelemetry/instrumentation'

so every consumer importing any type from @boringnode/queue/types had to install both, even
when they never touch the instrumentation.

Change

The re-export is removed. The package already ships a dedicated ./otel subpath for consumers who
do want the instrumentation types, so nothing becomes unreachable:

import type { QueueInstrumentationConfig } from '@boringnode/queue/otel'

JobDispatchMessage and JobExecuteMessage, exported one line above, are unaffected —
src/types/tracing_channels.ts imports no OpenTelemetry types.

The generated barrel now has no OpenTelemetry imports left:

// build/src/types/index.d.ts, this branch
export { … } from '../../job-PxhIiz8P.js';
export { JobDispatchMessage, JobExecuteMessage } from './tracing_channels.js';

Verification

Reproduction from the issue — npm pack of this branch installed in a clean project with
typescript@7.0.2, @types/node@25.9.4, knex@3.1.0, no @opentelemetry/* installed, and
import type { JobData } from '@boringnode/queue/types':

yarn typecheck, yarn lint and yarn format are clean (the two oxlint warnings in
src/otel.ts and tests/sync_adapter.spec.ts are pre-existing on main). Nothing changes at
runtime — export type is erased, so only the declaration surface is affected.

Note on the breaking change

This is breaking for anyone importing QueueInstrumentationConfig from @boringnode/queue/types
today. Given that the instrumentation is documented as experimental and has its own subpath, this
seemed like the right place for it, but say the word if you would rather schedule it for the next
major and I will hold the PR.