GeezerVison

…parameter name

…ype-based-serialization

refactor(requests)!: serialize body parameters by value type, not by parameter name

…ds from the spec (#487)

…java

The 106 generated data request classes keep their package, so nothing
changes for callers: src/generated/java now holds them, src/main/java
keeps the hand-written request infrastructure, and pom.xml adds the root
via build-helper-maven-plugin, which the compiler and the Javadoc pick
up from the compile sources.

codegen/generate.py writes to the new root, ci/check-docs.py scans both
roots, and AGENTS.md, CONTRIBUTING.md and README.md note the two-root
layout.

The generated request classes are pinned by codegen/generate.py --check,
and their optional setter boilerplate is exercised only where a fixture
uses the parameter, so counting it toward coverage reports a gap the
tests cannot close without covering every setter.

Every model's nested JsonUtil, AbstractModelObject.JsonUtil and
IModelObject.IJsonUtil were deprecated in 10.x in favour of ModelObjects and
no longer used by the library. PlaylistItemFactory goes with them: its only
method took a Gson JsonObject, and the reader now lives in the internal
ModelObjectGson, so the model_objects.utils package is no longer exported.

MIGRATION.md maps each removed call to its ModelObjects replacement.

Refs #461

…rated-source-root

refactor(build): move the generated request classes to src/generated/java

…ove-json-util

refactor(models)!: remove the deprecated JsonUtil classes

With the JsonUtil classes removed and request bodies taking List and Map, no
public signature takes or returns a Gson type anymore, so callers no longer
need to read Gson through this module. Gson stays a regular Maven
dependency; only a module that uses Gson itself without requiring it has to
add its own requires.

Refs #461

…n-requires

refactor(module)!: require Gson without re-exporting it

# Conflicts:
#	README.md

The code overview moved from the README on main, where requests are still
written by hand. On beta they are generated, so the overview now says where
the generated classes and SpotifyApi methods live and which two requests
stay hand-written, and the development setup lists the Python and PyYAML
the generator needs, with its commands.

…odegen

docs(contributing): describe the generated request classes

…NG.md

…endored-spec

docs(contributing): move the vendored spec convention into CONTRIBUTING.md

… body

…rams

fix(codegen)!: send a parameter offered in both query and body in the body

# Conflicts:
#	AGENTS.md
#	CONTRIBUTING.md