💡 feat: pattern search and paging for bk job log (--grep, context, --seek)

[elijahchancey]

Is your feature request related to a problem?

bk job log can only return the log from one end. --agent applies failure-focused windowing
and --max-tokens caps the size, which is a real improvement, but neither lets you ask for a
specific thing.

When you already know what you are looking for — a stack trace, a particular assertion, the
line where a flaky integration test logs its retry, a config value echoed near the top of a
long build — the choice today is to pull a window chosen by a heuristic and hope it contains
the match, or pull the whole log and grep locally at full token cost.

The official MCP server has this: search_logs takes a regex with before_context /
after_context / limit, plus read_logs with seek and limit for paging. Those exist
because "find the interesting part of a large log" is the common case, and the same reasoning
applies to the CLI.

Describe the solution you'd like.

Pattern selection on bk job log:

• --grep <regex> — return only matching lines
• -C/-B/-A <n> — context lines around each match, matching grep's spelling
• --max-matches <n> — cap results, since a broad pattern on a long log defeats the purpose
• --seek <line> / --limit <n> — page through a log without re-fetching it

Composing with the existing --max-tokens would be ideal: matches first, context trimmed to
fit the budget.

Describe alternatives you've considered.

Piping to grep locally. That works and is what I do now, but it transfers and renders the
entire log to discard nearly all of it — which is exactly the cost --max-tokens was added to
avoid. For a long log the difference is the whole point.

--agent windowing covers the "something failed, show me near the failure" case well. It does
not cover "show me every line matching this pattern", which is a different question.

Additional context

Version bk 3.55.0.