feat: add markdown() for the md output format, bump to 1.2.0

[jvmvik]

What

SerpApi's output parameter accepts md — per the Search API docs, "a markdown-formatted version optimized for LLMs and AI agents" — but this client exposed no way to ask for it. Reaching it meant dropping to the low-level call and knowing the endpoint path:

String md = client.get("/search", "md", parameter);

This adds markdown(), mirroring html():

public String markdown(Map<String, String> parameter) throws SerpApiException {
  return get("/search", "md", parameter);
}

Also corrects the get() javadoc, which listed the formats as (json, html, json_with_images) where the API documents (json, html, md).

Tests

MarkdownApiTest stubs the HTTP client with a recorder and asserts on the request this client builds — that output=md is sent, that the path is /search, and that constructor defaults (api_key, engine) still merge into the query. Runs offline, no SERPAPI_KEY needed.

Please verify before merging

I have not confirmed a real markdown response end-to-end. I have no API key in this environment, so the tests assert what we send, not what the backend returns. The evidence that md works is the documentation plus a markdown_endpoint field observed in live search_metadata. Someone with a key should sanity-check an actual call before this ships.

Two other points worth a reviewer's eye:

• Path choice. html() posts to /client, not /search. I used /search for markdown since that is what the docs describe, but if /client is the intended route for non-JSON output, this should match it.
• Error visibility. markdown() returns a raw String, so it bypasses the body-level error check proposed in fix: raise SerpApiException on an error in a 200 response body #6, which lives in json(). Given md is aimed at agent use, silently returning an error body as if it were content may matter more here than for html(). Left as-is to keep this PR focused.

🤖 Generated with Claude Code

---

Also in this PR: version bump to 1.2.0

Folded in rather than shipped separately:

• build.gradle 1.1.0 → 1.2.0
• README installation snippet and changelog (template and generated file)
• SerpApiHttp.VERSION, which had drifted to 1.0.0 while the project was at 1.1.0. It is public and never read anywhere in the library, so the stale value was only visible to callers.

demo/build.gradle still pins 1.0.0 and is deliberately untouched: it resolves a published JitPack artifact, and 1.2.0 does not exist there until this is released.