refactor(apl)!: rename authz/authn config keys

[araujof]

Summary

Renames the CPEX/APL authorization/authentication config keys for clarity. Breaking change (pre-1.0): old key names no longer parse.

Old	New
identity:	authentication: (global, route, policy-group)
policy:	authorization.pre_invocation: (or flat pre_invocation:)
post_policy:	authorization.post_invocation: (or flat post_invocation:)

The two authorization phases parse equivalently whether nested under an authorization: block or written flat on the section.

Closes #105.

Deliberately not renamed

The field-pipeline keys args: / result: stay as-is. They're aligned with the args.* / result.* attribute namespaces that predicates and interpolation read (require(args.include_ssn), ${args.repo_name}, args.ssn | redact) — renaming only the config block would have introduced a new inconsistency. (The issue originally proposed inputs/outputs; we tried it and rolled it back for exactly this reason.)

Internal APL IR (CompiledRoute, Phase) and the runtime attribute namespaces are unchanged.

Fail-closed by design

Legacy policy: / post_policy: / identity: keys are rejected loudly at parse/load time (in both the apl-core parser and cpex-core config loader) rather than silently ignored — a dropped authorization or authentication block would otherwise fail open.

Example

routes:
  - tool: get_employee
    authentication: [jwt-user, jwt-client]
    args:
      employee_id: "str"
    authorization:
      pre_invocation:
        - "require(authenticated)"
        - "delegation.depth > 2: deny"
      post_invocation:
        - "run(audit-log)"
    result:
      ssn: "str | redact(!perm.view_ssn)"

Also

• APL acronym spelled consistently as "Authorization Policy Language" (dropped the legacy "Attribute Policy Language").
• Docs, README, and CHANGELOG updated with the new surface and a BREAKING migration entry.

Testing

• cargo fmt --check, cargo clippy --workspace --all-targets, and full cargo test --workspace (all 55 suites) pass.
• Added coverage for nested-vs-flat equivalence and legacy-key rejection.
• Praxis regression: built praxis against this checkout (path dep) — compiles with no API/ABI break and its cpex policy integration test passes (401/200). The praxis-demos/demos/cpex configs were migrated to the new surface (separate PR in that repo) and verified to load through install_builtins + load_config_yaml.

[terylt]

Reviewed the rename mechanics end-to-end (parser, config loader, visitor, FFI/Go, docs). The core is solid and the fail-closed posture is real — a couple of things below, one of which I'd fix before merge.

What checks out

• Legacy rejection is thorough. policy: / post_policy: are rejected at every scope in both the apl-core parser (reject_legacy_keys in compile_route + compile_apl_blocks) and the cpex-core visitor (reject_legacy_apl_keys at global / default / policy-group / route). identity: is rejected at global, global.policies.*, global.defaults.*, and each route in reject_renamed_identity_key, which is actually called (config.rs:628) before validation. No scope silently drops a legacy key at the top level.
• FFI / Go bindings carry no stale config keys — the only identity left is the plugin kind identity/jwt, which is correctly untouched.
• Docs are fully converted — no lingering policy: / post_policy: / identity: in any example that would now hard-fail to load.
• Keeping args: / result: as-is is the right call — renaming only the config block while the args.* / result.* attribute namespaces stay would have traded one inconsistency for another.

Would fix before merge

Fail-open: a legacy key nested inside the new authorization: block is silently dropped.
AuthorizationYaml (parser.rs) has only pre_invocation / post_invocation — no #[serde(flatten)] capture and no deny_unknown_fields. So this:

routes:
  - tool: get_employee
    authorization:
      policy:            # <- legacy key, nested under the new wrapper
        - "require(authenticated)"

deserializes with pre_invocation empty, the inner policy silently ignored, and no error — the route loads with no authorization enforced. reject_legacy_keys doesn't catch it because it inspects RouteYaml.other, but policy here was consumed as part of the authorization value, so it never lands in other.

This is a plausible partial-migration mistake: reading the migration entry policy: → authorization.pre_invocation:, it's easy to write authorization: and then habitually keep policy: underneath. It's the exact fail-open the rest of the PR guards against, just at one nesting the guard doesn't reach.

Fix: add #[serde(deny_unknown_fields)] to AuthorizationYaml (it has no flatten, so this is safe, and it also catches typos like pre_invocaton:). A regression test for authorization: { policy: [...] } → load error would lock it in.

Minor

Both forms on the same section silently merge (double-execution footgun). compile_apl_blocks does auth_pre.iter().chain(raw.pre_invocation.iter()), so if a section declares both nested authorization.pre_invocation and flat pre_invocation, the entries concatenate rather than conflict. For idempotent denies that's harmless, but a run(audit-log), a Transform/mutating plugin, or a delegate() declared in both forms runs twice. Given the PR fails loud on almost everything else, silently merging both-on-the-same-section is a little inconsistent — worth either a doc note or rejecting the both-present case. (Mixing forms across different scopes — e.g. global nested, route flat — is fine; they're meant to stack.)

Naming (non-blocking)

Overall I'm fine with the direction — identity: → authentication: is a clear win, and pre_invocation / post_invocation fixes the old policy / post_policy asymmetry cleanly. One small semantic note for the record: the pre-invocation phase isn't a binary allow/deny — it compiles to effects that include Elicit (human approval / suspend), Taint, Delegate, and Plugin (which can modify_payload), so "authorization" slightly undersells it. The nice thing is the flat pre_invocation: / post_invocation: form sidesteps that entirely (it names when, not what), so anyone who finds authorization: too narrow can just use the flat keys. Since the wrapper is optional, this isn't something to block on — just worth a sentence in the docs that the phase runs a decision plus obligations/effects, so nobody reads authorization: as a pure gate.

[araujof]

All three addressed in ece499a:

1. Added #[serde(deny_unknown_fields)] to AuthorizationYaml. Nested legacy keys (authorization: { policy: ... }) and typos now fail to load. Tests added.
2. Declaring the same phase both nested and flat on one section is now a load error. Tests added.
3. Doc note: authorization carries effects (taint, delegate, plugin), not just allow/deny.

Suite, clippy, and rustfmt green.