This is a comment left during a code review.
Path: extensions/telegram/src/bot-handlers.runtime.ts
Line: 1245-1248

Comment:
**DM callback authorization no longer enforced**

The `!isGroup` branch was removed from the `authorizationMode` condition. Before this change, DM callbacks _always_ selected `"callback-allowlist"` mode, which enforces the sender authorization gate (the now-removed comment explicitly said: _"DM callbacks must enforce the same sender authorization gate as normal DM commands"_).

With the new condition:
```typescript
const authorizationMode: TelegramEventAuthorizationMode =
  !execApprovalButtonsEnabled && inlineButtonsScope === "allowlist"
    ? "callback-allowlist"
    : "callback-scope";
```

DM callbacks will use `"callback-scope"` whenever `inlineButtonsScope` is not `"allowlist"` (e.g., `"dm"`), regardless of whether the sender is paired. This means an unpaired DM user can interact with inline buttons (e.g., trigger model selection) even when `dmPolicy: "pairing"` is configured — because `"callback-scope"` does not enforce the pairing/allowlist gate.

The deleted test `"blocks DM model-selection callbacks for unpaired users when inline buttons are DM-scoped"` covered exactly this scenario and confirmed the regression.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/matrix/src/matrix/monitor/verification-events.ts
Line: 309

Comment:
**Matrix verification sender authorization removed**

The `isVerificationNoticeAuthorized` function was deleted along with both of its call sites. These were the only guards that checked whether a sender was allowed to trigger verification flows based on `dmPolicy`, `dmEnabled`, and the pairing allow-store.

After this change, any Matrix user — including senders blocked under `dmPolicy: "pairing"`, `dmPolicy: "allowlist"`, or `dmEnabled: false` — can initiate a verification flow and receive SAS emoji/decimal notices forwarded by the bot. The deleted integration tests confirmed this authorization gate was behavioral, not aspirational.

If the intent is to simplify the verification path, the PR should explain why sender authorization is safe to skip here (e.g., because the Matrix protocol's own verification handshake already guards the flow). Without that justification, this is a regression.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/msteams/src/monitor-handler.ts
Line: 178

Comment:
**MSTeams feedback invoke authorization removed**

The `isFeedbackInvokeAuthorized` check that guarded `handleFeedbackInvoke` was deleted. That function validated three conditions before processing a feedback invoke: (1) the DM sender passes the allowlist/pairing gate, (2) the team/channel route allowlist allows the conversation, and (3) the group sender is on the group allowlist.

With the check removed, any Teams user — regardless of DM policy, team/channel allowlist, or group allowlist — can submit feedback invokes and have them processed. If this is intentional, please add a comment explaining the rationale so reviewers can verify the security model.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: src/gateway/session-utils.ts
Line: 1823-1829

Comment:
**Freshest-session promotion logic removed**

`migrateAndPruneGatewaySessionStoreKey` previously selected the entry with the highest `updatedAt` across all case-variant duplicates and promoted it to the canonical key — ensuring the most recent session survived migration. The new code only copies any matching entry when the canonical key is absent.

If a user has both a stale and a fresh case-variant entry, the new code may promote the stale one depending on `storeKeys` ordering, causing the user to lose their most recent session state on startup. The two deleted tests validated that the freshest entry always wins.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: .vscode/settings.json
Line: 10-19

Comment:
**User-specific VS Code settings committed to shared repo**

The added `chat.agentSkillsLocations` block contains user-machine-specific paths (`~/.copilot/skills`, `~/.agents/skills`, `~/.claude/skills`) and a hard-coded extension version (`~/.vscode-server/extensions/synapsevscode.synapse-1.21.0/copilot/skills`). Committing these to `.vscode/settings.json` will push personal tool configurations to every contributor who pulls this branch.

Entries that are developer-specific should live in `.vscode/settings.json.local` (gitignored) or in VS Code's user settings, not in the project-level settings file.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: .work-folder-info
Line: 1

Comment:
**Editor-generated file accidentally committed**

`.work-folder-info` is a VS Code/Synapse workspace metadata file (`{"version":1}`). It has no meaning to other contributors and should be added to `.gitignore` rather than committed to the repository.

How can I resolve this? If you propose a fix, please make it concise.