fix(check_dataset_allowlist): import env_config in both invocation contexts

[Jammy2211]

autohands check_dataset_allowlist — newly registered as a CLI verb in #254 — crashes when run from a workspace root:

$ autohands check_dataset_allowlist
  File ".../autohands/check_dataset_allowlist.py", line 246, in check_capped_deletion
    from autohands.env_config import read_env_declaration
ModuleNotFoundError: No module named 'autohands'

Neither #253 nor #254 was wrong alone; the two combined to expose this. #253 added the autohands.env_config import to this module (fine — nothing invoked it as a script). #254 registered it as a dispatcher verb (fine — the module worked at the time it was surveyed). Found immediately after merging both, by actually running the new verb rather than assuming registration made it work.

The two paths differ

Context	What's on the path	Import that resolves
CLI verb — _python_in_autohands runs it as a script	autohands/ itself	import env_config
Library — pytest, import autohands.check_dataset_allowlist	the package's parent	from autohands import env_config

The flat form is the idiom the other guards here already use (validate_env_profiles.py:48). Supporting only one form breaks the other, so _env_config() tries flat first and falls back to package-qualified.

The quieter half

_releasing_tokens() wrapped its import in except Exception and returned the hardcoded {full_datasets, real_output} fallback. Under the CLI that swallowed the ImportError and never consulted ENV_DECLARATION_TOKENS at all — a silent degradation that still produced a green run.

It happened to give the right answer today, because those are currently the two releasing tokens. But the whole point of deriving from the map was that a future token releasing PYAUTO_SMALL_DATASETS starts protecting scripts with no edit here — and via the CLI it would have silently kept using the stale pair. The fallback is now a genuine last resort rather than the routine path.

This is why the fallback is worth being suspicious of in general: it converted a hard failure into a wrong-but-green one.

Verification

Both contexts, explicitly:

• CLI from a workspace root — runs clean (exit=0), and still reports the originating defect with exact file, line and resolved path when that workspace is reverted to its pre-fix state.
• Library — suite 375 passed, including a new regression test that simulates the CLI path by making autohands* imports fail, then asserts _releasing_tokens() still derives from the map rather than the fallback.
• Tenant-firewall gate OK.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F11sMzmaVWfU6NCz1PKVVb