tree downloads every cloud-synced file it lists

**Describe the bug**

The `tree` tool prints a line count beside each file, and gets that count by
reading every file in the walk.

Reading is exactly what hydrates a cloud placeholder. OneDrive Files On-Demand,
iCloud Drive and other File Provider backends leave "cloud-only" files on disk
as placeholders holding no data. Enumerating a directory and stat-ing its
entries is free and touches no network, but opening one for data blocks while
the provider downloads the whole file.

So a single `tree` call on a synced folder pulls the entire remote tree down.
The user never opened those files and the agent never edited them.

Three things make this worse than a slow tool call:

1. **The user is never asked.** `tree` is annotated `read_only_hint = true`, so
`permission_inspector.rs` files it under auto-approved and it never prompts.
The `developer` extension is `default_enabled: true`. Nothing surfaces that
the call is about to move gigabytes.
2. **It is invisible afterwards.** A read that fails returns a line count of 0,
so a large binary renders as `[0]` — the download happened, the output says
nothing about it.
3. **Metered links.** On tethering or a capped corporate connection this is a
real cost, not just latency.

Adjacent, same function: the walk has no entry ceiling and the reply has no cap,
so a synced home directory can bury the response at the default depth of 2.

Who it affects: anyone whose working directory sits inside a cloud-synced
folder. On Windows that is the default rather than the exception — with Known
Folder Move enabled, `Documents` and `Desktop` *are* OneDrive, so a user does
not have to do anything unusual to be inside one.

---

**To Reproduce**

1. On Windows, enable OneDrive Files On-Demand and ensure a folder holds
cloud-only files (Explorer shows a cloud icon rather than a green tick).
2. Point goose at that folder and have it call `tree`.
3. Watch the OneDrive tray icon — it starts syncing, and files that were
cloud-only become locally available.

Same on macOS with an iCloud Drive or OneDrive folder that has evicted files.

---

**Expected behavior**

Listing a directory should not download its contents. `tree` should decide from
metadata — which the walk already holds — whether reading a given file is safe,
rather than reading unconditionally. Both platforms expose a placeholder marker
in the file's attributes, and the directory entry already carries the size, so a
skipped file can still be described usefully.

---

**Please provide the following information**
- **OS & Arch:** Windows Server 2022 build 20348, AMD64 - the machine the measurements
in the comment below were taken on. Originally reported by a user on a corporate
Windows desktop whose exact build I did not capture. The same code path exists on
macOS with File Provider (iCloud Drive / OneDrive), but I have not measured it there.
- **Interface:** UI (the tool is reachable from CLI too)
- **Version:** observed on a downstream build tracking goose; the affected code
path is unchanged in current `main`, verified at 7a678c1c8
- **Extensions enabled:** `developer` (platform extension, on by default)
- **Provider & Model:** not provider-specific

---

**Additional context**

Source: `crates/goose/src/agents/platform_extensions/developer/tree.rs` —
`count_file_lines` calls `fs::read_to_string` on every entry that
`collect_tree` classifies as a file.

I have a patch with tests against current `main` and am happy to open the PR
once this reaches Ready.

The bug is in crates/goose/src/agents/platform_extensions/developer/tree.rs, specifically the count_file_lines function that calls fs::read_to_string. Start by examining the collect_tree logic and the file metadata available during the walk. On Windows, check for FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS; on macOS, check NSURLUbiquitousItemDownloadingStatusKey. Modify the logic to skip reading placeholder files, using size from metadata instead. Run tests to ensure tree still works on local files.

由索引模型根据 Issue 内容生成。