feat: an expired partition stays detached for a week unless the policy names a drop

[AlexeyShalaev]

Closes #106.

A LifecyclePolicy that doesn't name drop= now gets DropAfter(grace=timedelta(days=7)) instead of DropAfter() (DEFAULT_DROP_GRACE_DAYS in constants.py). That covers every flat config, every bare TablePartitionConfig(...) and every YAML table without drop:. An explicit DropAfter() keeps its zero grace, and DropNever() is unchanged. So only configurations that never chose a drop behave differently, and the difference is that disk is freed a week later.

Ships as feat: (1.9.0), not !: no API changes, and the new default only delays a destructive step. The changelog entry says who notices.

Docs:

• the configuration reference, the drop table in concepts, and rule 8 on the agents page now give the new default;
• the TablePartitionConfig docstring says where the drop is chosen;
• the tutorial (steps 8 and 9) and the CLI guide's --locks example no longer show a DROP in the same run as the detach.

Tests:

• The two unit tests that pinned the old default now pin the new one.
• About 70 integration tests exercise detach-and-drop mechanics on the default policy. Their config builders (tests/integration/nested_support.py, the scenario builder and two local builders) now spell out DropAfter() through a small drops_at_once decorator. It leaves a config alone when its policy names a drop itself, so the grace tests still test the grace.
• The CLI tests' YAML now states drop: {kind: drop_after, grace: P0D}.

Results: unit 2872 passed, integration (PG 17) 577 passed, ruff and mypy clean, docs build clean.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!