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

### 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 ` — return only matching lines
- `-C/-B/-A ` — context lines around each match, matching grep's spelling
- `--max-matches ` — cap results, since a broad pattern on a long log defeats the purpose
- `--seek ` / `--limit ` — 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`.

Start at the `bk job log` CLI entry point and inspect the existing `--agent` and `--max-tokens` behavior. Compare the issue's requested `search_logs`/`read_logs` semantics, then define how grep, context, match limits, seeking, paging, and token caps compose; done means each flag and their combinations produce bounded, documented log output.

Written by the indexing model from the issue text.