`read_file` does not report whether a line-range read reached EOF

This is something that has been a recurring problem for some time: I have a prompt for an agent to simply _append text to a file_, but the agent goes in circles (even powerful models!) trying to figure out where the file ends so that they can know where to append the text. This eats up credits, fills the context window, and wastes time. Sonnet 5 and GPT-5.6 Terra helped draft the description below.

---

The GitHub Copilot agent `read_file` tool accepts `filePath`, `startLine`, and `endLine`, but its response gives no explicit signal for whether the requested range reached or exceeded the end of the file. Text files are addressed by line number; the tool's own description states that binary files use the same parameters as byte offsets instead, and it's unclear whether the same gap, and the fix below, apply to that mode as well.

## Example
Given a text file with 50 lines, a call with `startLine=1, endLine=1000` returns all 50 lines of content, with nothing indicating that the file ended well short of the requested range. The response is indistinguishable from a complete, non-truncated read of a full 1000-line range.

## Why this matters
This breaks any workflow that needs to reliably locate the end of a file, such as appending new content after existing content. Without an explicit EOF signal, a caller has only two ways to infer it, and both are unreliable:

- Count the lines actually returned and compare that count against the requested range. This is easy to get wrong, and even done correctly it only tells the caller that *this* call proves EOF — nothing records that fact for later reference, so an agent can fail to recognize that a prior response already established it and issue further, redundant reads.
- Treat an empty result as proof the range starts past the end of the file. Nothing distinguishes that case from any other reason a range might legitimately return no content, so this inference isn't actually guaranteed by the tool's contract.

Getting this wrong has real consequences in both directions: mistaking a partial read for the file's end risks inserting new content into the middle of a file rather than at its end; failing to recognize an already-confirmed EOF wastes calls re-verifying the same fact.

## Requested change
Return structured metadata alongside the content, for example:

```ts
{
content: string;
linesReturned: number;
reachedEndOfFile: boolean;
totalLines?: number;
}
```

`reachedEndOfFile` alone would make append-at-EOF workflows deterministic rather than inferential. A `tail` mode, or a way to request a file's last N lines directly, would also help callers whose goal is the end of a file rather than a start-relative range.

## Scope note
This report describes behavior as observed by a calling agent, through the tool's returned result. Whether EOF or length information already exists at some lower level but simply isn't surfaced isn't something I can determine from this vantage point — the request is for that information to be exposed, however it is currently tracked internally.

---

```
Version: 1.134.0 (user setup)
Commit: 110a328ea54b42367b803ec53ee0bf52ef26b419
Date: 2026-08-18T18:24:44Z
Electron: 42.8.1
ElectronBuildId: 14906494
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
@github/copilot: 1.0.81-0
@github/copilot-sdk: 1.0.11
OS: 110a328ea54b42367b803ec53ee0bf52ef26b419
```