[Clipboard-Read P0] Add ClipboardRead device permission + telemetry + runtime flag

[Leah-Xia-Microsoft]

Summary

P0 of the Updated architecture for clipboard read using device permissions effort. This is the additive, no-behavior-change foundation that lets a later change move clipboard.read() onto the browser-native Clipboard API (navigator.clipboard.read) gated by a device-permission consent flow, replacing the deprecated host-proxied clipboard.readFromClipboard path.

• Feature: ADO 11070811 – Updated architecture for clipboard read using device permissions
• Task: ADO 12061800 – Clipboard-Read P0
• Epic (context): ADO 10815146 – Better device permissions for all MetaOS Apps
• Companion PR (host side): @metaos/hub-sdk adds the matching DevicePermission.ClipboardRead value.

Why

Today clipboard.read() is proxied: the app asks the host to read the OS clipboard and marshals a Blob back over the postMessage bridge. The capability was marked @deprecated (v2.54.0). The standards-based replacement is for the app to call navigator.clipboard.read() itself — but that requires (1) a clipboard-read device permission + consent, and (2) the host delegating clipboard-read via the iframe allow Permissions-Policy. This PR lays the guest-SDK groundwork for that; the actual read() rework is P2.

Changes (all additive)

File	Change
public/interfaces.ts	Add DevicePermission.ClipboardRead = 'clipboard-read'. The value deliberately matches the browser Permissions-Policy feature token so the host can emit it verbatim into the iframe allow attribute.
internal/telemetry.ts	Add Clipboard_HasPermission and Clipboard_RequestPermission ApiName entries, following the existing *_HasPermission / *_RequestPermission convention.
public/runtime.ts	Add an optional clipboard.native capability marker on the v4 runtime. When present, the host supports the native app-frame clipboard-read path; when absent (older hosts), consumers fall back to the legacy proxied path.

Not in this PR (scoped out / later phases)

• P2 – clipboard.hasPermission() / requestPermission() and the native read() implementation with proxy fallback (teams-js).
• P1 – host allow-list entry, consent gating, and IndexedDB migration (hub-sdk).
• No change to clipboard.write() or any existing permission. clipboard-write behavior is untouched.
• LNA and the broader permission-model unification are out of scope for this feature (separate epic work).

Compatibility

Purely additive: a new enum member, two telemetry names, and an optional runtime sub-flag. Nothing branches on these yet, so there is no behavior change and no impact on existing hosts or apps. Old hosts simply won't advertise clipboard.native.

Validation

• tsc --noEmit passes.
• eslint passes (0 warnings) on the changed files.
• Beachball changefile included (minor).

Reviewer notes

• ⚠️ Open question (blocks P1, not this PR): on Teams Desktop (Electron) and mobile, does clipboard-read flow through the iframe Permissions-Policy or through native OS/Electron permission handling? If native, P1/P2 need a native branch behind the same API. The clipboard.native marker is intentionally generic to accommodate either.
• The ClipboardRead naming/value is chosen to stay forward-compatible with any future unified device-permission enum, to avoid a later rename.

[github-actions]

This pull request contains changes to the runtime.ts file. If you, as the author of this PR, have made changes to the Runtime interface please review RUNTIME.md to determine if a new runtime version is required. Please reply to this comment stating what changes, if any, were made to the runtime object and whether a new runtime version was required.

[github-actions]

size-limit report 📦

Path	Size	Loading time (3g)	Running time (snapdragon)	Total time
packages/teams-js/dist/esm/packages/teams-js/src/index.js	202.98 KB (+0.02% 🔺)	4.1 s (+0.02% 🔺)	2.7 s (+15.26% 🔺)	6.7 s