fix(model-context): a share without limits/exposedTo accepts the registration's settings without a warning

[Copilot]

A <shae-worker expose-to-model-context> joining a registration opened with limits or exposedTo logged the tools under "shae-" are already registered with other limits or exposedTo once per element, although the element never asks for settings of its own — and has no way to. The behavior was correct; the warning was pure noise.

Cause. exposeShadowEnvsToModelContext() normalised a missing limits to {} before joining, and joinSharedExposure() compared settings by value. "Not given" was indistinguishable from "explicitly {}", so every element join read as a conflict with whatever the opener had set.

Changes

• exposeShadowEnvsToModelContext.ts — pass through only the settings the caller actually gave; "not given" stays distinguishable from "explicitly set".
• sharedExposure.ts — new internal RequestedExposureSettings (limits/exposedTo optional); open() resolves the defaults (limits ?? {}), so opener semantics are unchanged; the by-value sameSettings became conflicts(inEffect, requested):

const conflicts = (inEffect: ExposureSettings, requested: RequestedExposureSettings): boolean =>
  (requested.limits !== undefined && JSON.stringify(requested.limits) !== JSON.stringify(inEffect.limits)) ||
  (requested.exposedTo !== undefined && JSON.stringify(requested.exposedTo) !== JSON.stringify(inEffect.exposedTo));

The warning's ignored payload now names only what the joiner passed and what differs.

Effect. Element joins are silent whatever the opener set; a call that explicitly passes a differing limits or exposedTo — including an explicit {} against an opener's limits — is still reported. No API change.

Tests. Three new specs: opener with limits/exposedTo + joiner without → no warning, opener's limits in effect (and gone once the opener leaves); per-setting conflict reporting, same values vs. differing ones; an element joining a registration opened with limits + exposedTo → no warning (the reported scenario). All three fail on the unfixed source.

Docs. CHANGELOG.md (Unreleased), docs/api-reference.md, docs/best-practices.md, and a dated amendment in docs/proposals/web-mcp-shadow-envs.md: a share that leaves a setting out accepts what is in effect; only a value of its own that differs is reported.

• Fixes model-context: <shae-worker expose-to-model-context> warns about conflicting limits it never set #9

[Copilot]

Copilot review overview

🔵 Needs a closer look

Mixed matching and conflicting settings produce an inaccurate ignored warning payload.

Review effort: Balanced
Findings: None

What changed in this PR

Fixes noisy model-context warnings when a share omits registration settings.

Changes:

• Preserves omitted limits and exposedTo settings.
• Adds conflict-focused sharing behavior and regression tests.
• Updates API documentation, proposal, and changelog.

File	Description
sharedExposure.ts	Handles optional requested settings and conflicts.
exposeShadowEnvsToModelContext.ts	Preserves omitted settings.
exposeShadowEnvsToModelContext.spec.ts	Tests sharing and warnings.
ShaeWorkerElement.modelContext.spec.ts	Tests silent element joins.
best-practices.md	Documents sharing behavior.
api-reference.md	Clarifies omitted settings.
CHANGELOG.md	Records the bug fix.
web-mcp-shadow-envs.md	Amends the design record.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.