feat: add network request detail and filtering for request tracking

[ChunHao-dev]

Summary

Add network request <requestId> command and filtering flags (--type, --method, --status) for network requests.

fixed #932

Changes

• network request <requestId> — view full request/response detail including response body via CDP Network.getResponseBody
• --type xhr,fetch — filter by resource type (comma-separated)
• --method POST — filter by HTTP method
• --status 2xx — filter by status code (exact 200, class 2xx, range 400-499)
• Extend TrackedRequest with request_id, post_data, status, response_headers, mime_type
• Network.responseReceived now also updates tracked_requests (previously only HAR entries)
• Updated README, SKILL.md, docs/commands MDX, and help text

Test plan

• cargo fmt --check ✅
• cargo clippy -- -D warnings ✅
• cargo test — 490 passed, 0 failed ✅
• Added 7 parse tests for filter flags and network request command
• Added matches_status_filter unit tests (exact, class, range, None)

[vercel]

@ChunHao-dev is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[ctate]

Thanks for this, @ChunHao-dev! Filters and network request <requestId> all work correctly end-to-end. Tests and clippy pass clean.

One change needed: network requests output doesn't show request IDs, so there's no way to discover the ID for network request <requestId> without --json. Please add the ID (and status) to the formatted line in cli/src/output.rs ~line 377, e.g.:

[19234.3] POST https://httpbin.org/post (Fetch) 200

[ChunHao-dev]

Done! Added request ID and status to the formatted output in output.rs.

Example:
[19234.3] POST https://httpbin.org/post (Fetch) 200

Requests without a response yet omit the status code.

[ChunHao-dev]

I found some existing behaviors during testing:

1. Lazy activation — Network.enable is sent only on the first network requests call. So if the user runs open first, requests from page load are missed. This is the root cause of [Bug] network requests does not capture page navigations — only XHR/fetch (distinct from #130) #555.

2. Single-tab only — Network.enable is sent to the current active tab. If the user opens a new tab, it won't be tracked.

3. No limit — tracked_requests keeps growing. On sites like x.com that poll frequently, the list gets very long.

These are not from this PR — they already existed before.

I thought about adding a tip in the docs to tell users: run network requests before open to capture page load requests. But I want to ask you first — should I add it? And where?

Also, I can open a follow-up issue and PR to improve these (e.g. re-send Network.enable on tab switch, add a max size for tracked_requests). Let me know if you'd like that!

[ChunHao-dev]

@ctate Changes addressed — ready for re-review when you get a chance.

[ctate]

Looks great. Thank you @ChunHao-dev