[bug-bash] Sequential script commands leak their result into rm as implicit pipe input

Start by reading RmCommand.ExecuteAsync and its container visitor, where the issue says pipe input is inferred from commandState.Result. Trace how sequential script statements carry CommandState into rm and compare that with a standalone rm invocation. Add or locate a regression test for the script sequence; done means exact-ID dry runs return count 1 with id and etag after an earlier command, without requiring an explicit pipeline.

Environment

Windows x64, CosmosDBShell 1.1.291-preview (db49321323).
Reproduced against a disposable Azure NoSQL container with partition key /pk,
using Azure CLI authentication and Gateway mode.

Setup

PowerShell setup creates a unique disposable shared-throughput database
(400 RU/s), an Items container partitioned by /pk, and one synthetic item.
No existing data is required. Set the three account environment variables first:

foreach ($name in @('COSMOS_ENDPOINT', 'AZURE_SUBSCRIPTION_ID', 'COSMOS_RESOURCE_GROUP')) {
    if ([string]::IsNullOrWhiteSpace([Environment]::GetEnvironmentVariable($name))) {
        throw "Set $name to an authorized test account value before continuing."
    }
}
$package = "$env:USERPROFILE\.dotnet\tools\.store\cosmosdbshell\1.1.291-preview"
$shell = Join-Path $package 'cosmosdbshell.win-x64\1.1.291-preview\tools\net10.0\win-x64\CosmosDBShell.exe'
& $shell --version
$connection = @(
    '--connect', $env:COSMOS_ENDPOINT,
    '--connect-azure-cli', '--connect-mode', 'gateway',
    '--connect-subscription', $env:AZURE_SUBSCRIPTION_ID,
    '--connect-resource-group', $env:COSMOS_RESOURCE_GROUP,
    '--output', 'json', '--quiet'
)
$work = Join-Path ([IO.Path]::GetTempPath()) ('cosmos-rm-' + [guid]::NewGuid().ToString('N'))
New-Item -ItemType Directory -Path $work | Out-Null
Set-Location $work
$db = 'BugBash_Rm_' + [guid]::NewGuid().ToString('N')
& $shell @connection -c "mkdb $db --scale=m --ru=400"
if ($LASTEXITCODE -ne 0) { throw 'Fixture database creation failed; stop.' }
& $shell @connection --database $db -c 'mkcon Items /pk'
if ($LASTEXITCODE -ne 0) { throw 'Fixture container creation failed; stop.' }
'[{"id":"safe-a","pk":"p1","count":1}]' | Set-Content -Encoding utf8 .\seed.json
& $shell @connection --database $db --container Items -c 'import seed.json --concurrency=1'
if ($LASTEXITCODE -ne 0) { throw 'Fixture import failed; stop.' }

Repro

Create and execute the exact failing script:

@"
cd /$db/Items
rm safe-a --key=id --partition-key=p1 --dry-run > preview.json
"@ | Set-Content -Encoding utf8 .\repro.csh
& $shell @connection -c 'repro.csh'
$previewExit = $LASTEXITCODE
Get-Content -Raw .\preview.json
"Exit code: $previewExit"

There is no pipe operator.

Expected

The exact-ID dry run should independently read the existing item and return
count 1, id "safe-a", partitionKey "p1", and the current etag.

Actual

The process exits 0 and preview.json contains:

{"type":"item","count":0,"dryRun":true,"partitionKey":"p1"}

The item still exists. Running the same rm command as the sole command in a
fresh invocation returns count 1 with id and etag.

Working control: run the same exact-ID dry run as the only command, selecting
the target through startup options instead of a preceding cd:

& $shell @connection --database $db --container Items -c 'rm safe-a --key=id --partition-key=p1 --dry-run'

Actual: count 1, id "safe-a", partitionKey "p1", and the current etag.

A second exact script variant also demonstrates the leak:

@'
print safe-a p1 > before.json
rm safe-a --key=id --partition-key=p1 --dry-run > after-print.json
'@ | Set-Content -Encoding utf8 .\after-print.csh
& $shell @connection --database $db --container Items -c 'after-print.csh'
Get-Content -Raw .\after-print.json

Here count is 1, but id and etag are absent. The prior point-read result is
incorrectly interpreted as piped input, bypassing exact-ID preview behavior.
An automation step that subsequently reads preview.etag therefore fails.

Controls and impact

• The point read confirmed the item exists.
• A fresh single-command preview returned count 1 and the current etag.
• Explicitly clearing the previous result with a helper script containing only
  return, between cd and rm, restored count 1, id, and etag.
• A separate single-command deletion using the verified ETag deleted exactly
  one item; a subsequent point read confirmed it absent.
• These controls distinguish the bug from missing fixture data or failed import.
• This can silently turn script deletion/preview steps into no-ops or remove
  fields needed by ETag-protected automation. No unintended deletion was observed.

Investigation lead

RmCommand.ExecuteAsync and its container visitor infer pipe input solely from
commandState.Result != null. Script execution carries CommandState between
sequential statements, allowing an earlier cd/print result to satisfy that test
without an explicit pipeline. Exact-ID mode is bypassed when hasPipeInput is true.

Workaround: run the exact-ID operation in a separate invocation, using startup
database/container options rather than a preceding cd statement.

Cleanup

The failing operations above are dry runs and delete no items. Delete only the
database created by the setup commands when finished:

& $shell @connection -c "rmdb $db true"

The databases used during the original tests were deleted and independently
verified absent through Azure Resource Manager. No product fix was implemented.