Known limitation: neighbor charm can drop the tested endpoint between scheduling and running a test execution

## Description

The test scheduler creates a test execution pairing a new charm version with "the
latest stable" version of each neighboring charm at schedule time. Before the
execution actually runs, the neighbor's stable channel can be updated to a revision
that no longer has the endpoint used for that integration, so the test fails for
reasons unrelated to the charm under test.

## Why won't-fix

This is inherent to testing against a moving target ("latest stable"). Pinning the
neighbor at schedule time defeats that purpose; re-validating at execution time adds
real complexity for a narrow, infrequent race window. No good fix exists; tracking as
a known limitation.

Read the issue description first to understand the scheduling race: a neighbor charm can change its stable revision before the test execution runs. No file, test, or implementation change is identified; the issue records a known limitation and explicitly says it will not be fixed.

Written by the indexing model from the issue text.