Cut and tag v0.7.0, publish to PyPI, and archive to Zenodo (JOSS needs a release matching the paper)

[shivamlalakiya]

What's wrong

PyPI serves 0.6.0. main now carries the merged JOSS paper (#103), which describes code PyPI
does not ship: conformal_pvalue, the as_of cutoff on the encounter transformers (#92),
drop_repeat_donors (#100), stratified KNN imputation (#99), the corrected generator (#102) and
scripts/leakage_experiment.py (#101).

A JOSS reviewer works from this checklist item:

Installation: Does installation proceed as outlined in the documentation?

They will pip install philanthropy, get a version older than the paper describes, and file that
as an issue. JOSS also wants the submission tied to an archived release with a DOI matching the
reviewed state.

What this is not

Not 1.0.0. JOSS needs a tagged, archived release, not a major one. Tagging 1.0.0 activates
the Tier-1 deprecation promise in CHANGELOG.md (a breaking change needs a major release preceded
by a full published minor of DeprecationWarning), which is real weight for a solo maintainer, and
1.0.0 is the only announcement-shaped event this project gets. Spend it on an announcement, not on
a submission prerequisite.

docs/reference/index.md already states that deprecation policy as live while RELEASING.md says
pre-1.0 minors may break. That contradiction resolves itself when 1.0.0 is tagged, and not before,
so leaving it until then is deliberate.

Where

File	Locate with
the version to bump	grep -n '^version' pyproject.toml
the citation metadata that must follow it	grep -n 'version:|date-released' CITATION.cff
the release checklist to follow exactly	grep -n '^#\+' RELEASING.md
the unreleased section to close	grep -n '\[Unreleased\]' CHANGELOG.md
the supported-version table	`grep -n '

What to change

1. Land the two open PRs first, a few days apart: test: close the EncounterRecencyTransformer coverage gap (79% -> 98% branch) #107 and fix: reject network-scheme paths at the read boundary #123. Do not batch them. See the
   commit-distribution note in the tracking issue.
2. Close ## [Unreleased] in CHANGELOG.md as ## [0.7.0] with the real date.
3. Bump version in pyproject.toml to 0.7.0.
4. Update CITATION.cff: version: 0.7.0 and a real date-released. Leave the concept DOI alone;
   it resolves to all versions by design and the comment in that file explains why.
5. Update the supported-version table in SECURITY.md, per RELEASING.md.
6. Re-run examples/quickstart.ipynb end to end against the built wheel, per RELEASING.md. It
   installs from PyPI, so it must be re-run after the publish, not before.
7. Tag v0.7.0 and publish to PyPI.
8. Let Zenodo mint the version DOI from the GitHub release. That version DOI, not the concept
   DOI, is what goes in the JOSS submission form.

Tests to add or extend

None. This is a release, not a code change. make ci and make riskcov must be green on main
before the tag, and the pre-push hook already runs the full suite.

Done when

# Exits 0 only once the metadata agrees with itself at 0.7.0.
python -c "import tomllib,pathlib; \
  v = tomllib.loads(pathlib.Path('pyproject.toml').read_text())['project']['version']; \
  assert v == '0.7.0', v"
grep -q 'version: 0.7.0' CITATION.cff
grep -q '\[0.7.0\]' CHANGELOG.md
git tag | grep -qx v0.7.0
make ci
make riskcov

Then, outside the shell: PyPI serves 0.7.0, the Colab notebook runs green against it, and the
Zenodo record for v0.7.0 exists with its own DOI.

Not a good first issue

Tagging a release is effectively irreversible and requires PyPI and Zenodo credentials. Maintainer
only.