[lesnik512]

Closes #314.
Closes #318.

This deletes everything that 1.16.0 deprecated. That release added the DeprecationWarnings (#350), so the 2.0 half of both issues is now due.

Removed

From #314:

Name	Use instead
OpentelemetryConfig (opentelemetry_instrument)	OpenTelemetryConfig
FreeBootstrapperConfig (lite_bootstrap, free_bootstrapper)	FreeConfig
IGNORED_STRUCTLOG_ATTRIBUTES (sentry_instrument)	logging_factory.STRUCTLOG_META_KEYS
AddressProtocol, RequestProtocol, ScopeType (logging_factory, logging_instrument)	nothing. The private _AddressProtocol, _RequestProtocol and _ScopeType they pointed at had no other use, so they are gone too.
not_ready_message and check_dependencies on an instrument, forwarded by BaseInstrument.__init_subclass__	not_configured_reason, dependencies_installed

_RENAMED_ATTRIBUTES and the __init_subclass__ override are deleted. The bootstrapper's own not_ready_message is not part of this and stays.

From #318, the alias fields and their _renamed_fields entries:

Config	Old field	New field
FastAPIConfig	prometheus_instrumentator_params, prometheus_instrument_params, prometheus_expose_params	prometheus_*_additional_params
FastMcpConfig	prometheus_instrumentator_params, prometheus_instrument_params	prometheus_*_additional_params
LitestarConfig	swagger_extra_params	swagger_additional_params
all three	fastapi_ / fastmcp_ / litestar_logging_middleware_enabled	logging_access_log_enabled

CONTEXT.md loses the sentence saying an instrument written against not_ready_message still works.

Kept

deprecated_module_getattr and BaseConfig._renamed_fields stay, with nothing using them. AGENTS.md's versioning rules name them as the way to deprecate a module-level name and a config field, so the next rename in 2.x needs them. Their warning used to say "removed in lite-bootstrap 2.0", which would be wrong for anything deprecated from now on. It now reads the version from helpers.warn.NEXT_MAJOR_VERSION = "3.0". If you would rather delete both helpers and rewrite the AGENTS.md rule, that's a small follow-up.

Tests

Written first. These failed on main:

• test_a_name_deprecated_in_1_x_is_gone, one case per module and name, expects AttributeError. On main each name warned and resolved.
• test_a_field_name_deprecated_in_1_x_is_rejected, one case per config and field, expects TypeError. On main each one forwarded with a warning.
• The two helper tests that match on "lite-bootstrap 3.0".

The alias-mechanics tests now run against test-only targets: a deprecated_module_getattr built in the test module, and a RenamingConfig with one renamed field. They keep the checks from 1.16.0: the warning attribution, setting both names raising ConfigurationError, from_dict, from_object and dataclasses.replace. The two legacy-instrument tests in test_base_instrument.py are deleted, as #314 says. The star-import test is gone too: no lite-bootstrap module has a __getattr__ any more.

The full suite passes, 551 tests at 100% coverage (just test-ci). just lint (including ty), just adr-check and just docs-build pass too. The two issues' check is to grep for the old names. Under lite_bootstrap/, docs/, benchmarks/, scripts/, README.md, AGENTS.md and CONTEXT.md it finds only the bootstrapper's own not_ready_message and Litestar's litestar.enums.ScopeType.

Breaking changes

• Importing any removed name raises ImportError, and accessing one as an attribute raises AttributeError.
• Passing a removed field to a config raises TypeError. from_dict and from_object drop unknown keys, so a settings source that still uses an old field name falls back to the default without an error. That is the existing from_dict contract, and Rename the inconsistent escape-hatch and access-log config fields #318 lists it as a 2.0 break.
• An out-of-tree instrument that still defines not_ready_message or check_dependencies gets no warning. Its skip reason becomes empty, and its dependency check returns True, so it is built even when its package is missing.

Two follow-ups, not in either issue:

• __init_subclass__ could raise on the legacy instrument names for one more major instead of ignoring them.
• from_dict could reject the removed field names.

I haven't done either.