fix: eliminate cache-memory dependency in update-instructions workflow

[vhvb1989]

Summary

Fixes #8702

Replace the cache-memory tool with a GitHub API query for the last successful workflow run in the update-instructions-from-pr-reviews agentic workflow.

Problem

On first run, last-run.txt didn't exist in cache. The agent correctly called missing_data with cache_memory_miss (as instructed by the cache-memory system), but gh-aw's detection layer interpreted this as a prompt misconfiguration rather than a legitimate first-run condition.

Fix

Eliminate the cache entirely. Instead of reading/writing last-run.txt in cache-memory, the agent now queries the GitHub API for the most recent successful run of this workflow to determine the PR range starting point.

Changes

• Removed cache-memory: tool from the workflow frontmatter
• Rewrote Step 1 fallback to query the last successful workflow run via GitHub API
• Removed Step 8 ("Record the run") — no cache to write to; the workflow run history IS the state
• Added actions: read permission so the agent can list workflow runs

Why not just fix the prompt?

The cache-memory approach is inherently fragile for a weekly workflow:

• GitHub Actions cache has a 7-day unused-entry eviction policy
• A weekly Monday schedule sits right at the eviction edge — a skipped week means cache loss and redundant 6-month mining every time
• The GitHub API workflow run history is always available and is the natural source of truth

Per richardpark-msft's comment: "If you can get it to just query that detail directly you can eliminate a dependency on that cache altogether."

[Copilot]

Pull request overview

This PR updates the Update Instructions From PR Reviews agentic workflow definition to remove reliance on cache-memory and instead derive the “since last run” starting point from GitHub Actions workflow run history.

Changes:

• Removes the cache-memory tool dependency and the “record the run” step (state now lives in workflow run history).
• Adds actions: read permission and updates the range-determination logic to use the last successful run timestamp.

[github-actions]

📋 Prioritization Note

Thanks for the contribution! The linked issue isn't in the current milestone yet.
Review may take a bit longer — reach out to @rajeshkamal5050 or @kristenwomack if you'd like to discuss prioritization.

[jongio]

Clean fix. Replacing the cache-memory tool with a workflow-run-history query is the right call: you eliminate a 7-day eviction hazard and gain a source of truth that's always available. The fallback chain (explicit date > last successful run timestamp > 6-month cap) handles the edge cases well.

Two quick notes:

1. Lock file: the .lock.yml wasn't regenerated in this branch (same SHA as main). You'll need a gh aw compile pass before merge so the runtime picks up the new logic.

2. Bot comment on workflow name is a false positive: the instruction says "list recent workflow runs for this workflow (Update Instructions From PR Reviews)" and the lock.yml's name: field is exactly that string, so the agent will resolve it correctly.

Good to go once the lock file is refreshed.