Permission prompt suggests pattern that won't match piped commands

Description

When a Bash command uses a pipeline (e.g., something | tee /tmp/file.log), the permission prompt offers "Yes, and don't ask again for: tee:*" — but this pattern only matches commands that start with tee, not commands where tee appears later in a pipeline.

Steps to reproduce

1. Add "Bash(tee:*)" to the allow list in ~/.claude/settings.json
2. Have Claude Code run a command like:

``
build_metal/baspacho/benchmarking/lu_bench -d test_data/c6288_sequence -v 2>&1 | tee /tmp/claude/lu_bench_fixed.log
``

1. Despite Bash(tee:*) being in the allow list, the permission prompt still appears
2. The prompt suggests "Yes, and don't ask again for: tee:*" — which is the exact pattern already in the allow list

Expected behavior

Either:

• Option A: The permission system should recognize tee in a pipeline and match it against Bash(tee:*) in the allow list (i.e., match each pipeline stage independently)
• Option B: The suggested "don't ask again" pattern should reflect the actual command prefix that would need to match (e.g., build_metal/*:* or build_metal/baspacho/benchmarking/lu_bench:*), not an interior pipeline command that won't match

Actual behavior

• Bash(tee:*) in the allow list has no effect on commands where tee is in a pipeline
• The "don't ask again for: tee:*" suggestion is a no-op — selecting it adds a pattern identical to what's already configured, and the prompt will appear again next time

Impact

Users who accept the "don't ask again" suggestion believe the issue is resolved, but the same prompt reappears on the next piped command. This is confusing and erodes trust in the permission system configuration.