Proactively detect and report missing APIView links or metadata in SDK PRs

## Problem

During the Azure Key Vault team's SDK release, pull requests were missing expected APIView links due to upstream tooling issues. The agent did not detect or compensate for this gap — it silently accepted the missing metadata, leaving the team without a path to find their API review.

When tooling fails to populate expected metadata, the agent should catch and surface the gap rather than silently passing through incomplete data.

**Source:** First-time service team feedback (Azure Key Vault)

## Proposed Solution

When the agent inspects SDK pull requests and expected metadata is missing:

1. **Detect the absence** — check for expected fields like APIView link, approval status, and CI check results
2. **Report it explicitly** — don't silently skip missing data
3. **Provide a fallback path** — give the user a way to find the information manually
4. **Flag potential tooling issues** — make it clear that the absence may be a tooling bug, not a user error

### Example output
> ⚠️ **Expected APIView link not found in this PR**
> This may be a tooling issue — the APIView link is normally populated automatically.
> 👉 You can locate your API review manually at https://apiview.dev
> 🔍 Search for package: `Azure.Security.KeyVault.Keys`

## Acceptance Criteria

- [ ] Agent checks for expected metadata (APIView link, approval status) in SDK PRs
- [ ] Missing metadata triggers an explicit warning — not silent omission
- [ ] Warning includes a manual fallback path (e.g., direct link to apiview.dev with search guidance)
- [ ] Warning clearly indicates this may be a tooling issue (not user error)
- [ ] Agent does not block on missing metadata — it warns and continues

## User Impact

Prevents silent failures where tooling gaps leave service teams without critical information. Builds resilience into the release workflow by ensuring users always have a path forward, even when upstream tooling doesn't populate expected data.

No source files or tests are named. Start by locating the agent entry point that inspects SDK pull-request metadata and any existing warning or reporting tests. Trace how APIView links, approval status, and CI results are handled; done means missing metadata produces a non-blocking warning with manual APIView guidance and the workflow continues.

Written by the indexing model from the issue text.