fix(tools): allow relative script paths in exec guard

[bogdanovich]

Summary

• stop exec sandbox path scanning from misclassifying relative script paths like scripts/send_voice_reply_telegram.sh as absolute escaped paths
• pass inbound topic metadata into tool context and expose it through the shared tool facade
• add a regression test for slash-containing relative script commands

Problem

For restricted workspaces, exec currently scans command strings for absolute paths using a regex that matches any /... segment. That also catches the slash substring inside a relative command token such as:

• scripts/send_voice_reply_telegram.sh

The guard then treats the matched fragment as if it were an absolute path (/send_voice_reply_telegram.sh) and rejects the command with:

• Command blocked by safety guard (path outside working dir)

That is a false positive. The command is workspace-local and should be allowed.

This surfaced in a Telegram voice-reply workflow, but the bug is not Telegram-specific. Any workflow that executes a relative script path containing / from a restricted workspace can hit the same guard failure.

Fix

• in pkg/tools/shell.go, skip regex matches that are only slash-fragments inside a larger relative token instead of standalone absolute paths
• keep existing blocking behavior for real absolute paths and URL-bypass attempts
• add TestShellTool_RelativeScriptPathNotMisclassifiedAsAbsolute to cover the regression

Why this should be upstream

This is a core exec sandbox correctness fix:

• it preserves the sandbox boundary for real absolute paths
• it removes a false positive for legitimate relative commands
• it benefits any channel, MCP workflow, or local skill that shells out to workspace scripts

Validation

• go test ./pkg/tools -run 'TestShellTool_(RelativeScriptPathNotMisclassifiedAsAbsolute|URLBypassPrevented|FileURISandboxing)'
• rebuilt and ran the fix against a restricted Telegram workspace where the regression originally reproduced

[bogdanovich]

Fixed the workflow failures.