fix(browserstack-service): declare browser.setCustomTags on WebdriverIO.Browser type (SDK-6882)

[harshit-browserstack]

What

Declares browser.setCustomTags(key, value) on the global WebdriverIO.Browser interface so TypeScript consumers of @wdio/browserstack-service can call it without a compile error.

Why

Jira SDK-6882: a WebdriverIO + Mocha (TypeScript) customer on @wdio/browserstack-service@9.29.1 hit:

Property 'setCustomTags' does not exist on type 'Browser'.

The command works at runtime (the service attaches it, and the customer's test calling it passed) — the failure is compile-time only. The setCustomTags/a11y declarations live in src/@types/bstack-service-types.d.ts but that file uses declare namespace and is pulled in only via /// <reference path> from internal source, so it is never emitted into the shipped build/index.d.ts (the package types entry). Consumers therefore receive no WebdriverIO.Browser augmentation.

Fix

Add the augmentation to the declare global { namespace WebdriverIO {} } block in src/index.ts, which is emitted to build/index.d.ts and delivered to consumers:

interface Browser {
    setCustomTags: (key: string, value: string) => Promise<void>
}

Merges cleanly with the existing ambient declaration (identical signature).

Verification

• Pristine published @wdio/browserstack-service@9.29.1 → tsc reproduces the exact TS2339 (exit 2).
• With this change built (pnpm build, exit 0), the regenerated build/index.d.ts emits the interface Browser { setCustomTags } augmentation; the same minimal project then compiles clean (tsc exit 0).
• 0 TS errors; no duplicate-identifier conflict. Runtime behavior unchanged.

Scope / follow-up

Scoped to setCustomTags (the reported symptom). The a11y methods (getAccessibilityResults, performScan, …) share the same non-shipping cause and remain untyped for consumers — a follow-up could wire the full bstack-service-types.d.ts (incl. MultiRemoteBrowser) into the shipped types.

🤖 Generated with Claude Code