Title: Feature: Integrate Effect Ethos for Deontic Reasoning and Action-Guarding

Is your feature request related to a problem? Please describe.

The DeepCausality library currently provides a powerful framework for causal reasoning (CausaloidGraph) and a mechanism for triggering actions based on causal states (CSM). However, there is no formal layer to govern, verify, or block these actions based on a set of rules, norms, or ethical principles. This creates a gap between causal inference and safe, verifiable real-world intervention, which is a critical requirement for deploying causal AI in regulated or safety-critical domains.

As outlined in "The Teleology of the Effect Propagation Process," the EffectEthos is designed to fill this gap by providing a computable and auditable safety layer based on the Defeasible Deontic Inheritance Calculus (DDIC).

Describe the solution you'd like

This issue proposes the full integration of the EffectEthos into the CSM workflow. The EffectEthos will act as a "deontic gatekeeper," evaluating every proposed action from the CSM against a configurable set of norms (Teloids) before it can be executed.

This will allow users to define complex safety and operational rules (e.g., "the drone must not fly in the rain," "the robot arm must not move if a human is present") that are formally verified at runtime.

Architectural Overview

The core components (Teloid, TeloidStore, TeloidGraph, EffectEthos) have been implemented. The main task is to integrate them with the existing CSM to create a complete "Reason -> Verify -> Act" pipeline.

The new workflow will be:

1. A CausalState within the CSM is evaluated and found to be active.
2. Instead of firing the associated CausalAction immediately, the CSM creates a ProposedAction.
3. The CSM submits this ProposedAction to its configured EffectEthos instance.
4. The EffectEthos evaluates the action against all relevant norms and returns a Verdict.
5. The CSM inspects the Verdict. The CausalAction is only executed if the verdict is Obligatory or Optional. It is blocked if the verdict is Impermissible.

Task Breakdown & Implementation Plan

• 1. Finalize EffectEthos High-Level API:

  • Implement the fluent builder API (add_norm, link_inheritance, link_defeasance) for easy construction. (Already completed).
  • Implement the build() method (by renaming verify_graph) as the explicit finalization step. (Partially complete, needs rename).
  • Ensure all public API methods are covered by the new test suite. (Partially complete).

• 2. Integrate EffectEthos into the CSM:

  • Modify the CSM struct to hold an instance of EffectEthos.
  • Update the CSM::new() constructor to accept a configured and built EffectEthos.
  • Modify the eval_single_state and eval_all_states methods in the CSM to implement the "Reason -> Verify -> Act" workflow described above.

• 3. Refine PredicateFn and ProposedAction Interaction:

  • Ensure the ProposedAction struct can carry all necessary parameters from a CausalState evaluation.
  • Review the PredicateFn signature (fn(&Context, &ProposedAction) -> bool) to ensure it's robust enough for writing complex, context-aware activation rules for norms.

• 4. Create a Comprehensive Example:

  • Add a new example in the /examples directory that demonstrates the full end-to-end use case.
  • The example should show:
    1. Building a CausaloidGraph.
    2. Building an EffectEthos with several conflicting and inheriting norms.
    3. Initializing a CSM with the causal model and the ethos.
    4. Running the CSM and showing how an Impermissible verdict successfully blocks an action.

• 5. Update Documentation:

  • Update the main library documentation and the telos_types module documentation to reflect the new API and workflow.
  • Provide clear examples on how to build and use the EffectEthos as a safety layer.

Acceptance Criteria

• EffectEthos can be constructed with the fluent API.
• CSM can be configured with an EffectEthos.
• CSM evaluation calls EffectEthos::evaluate_action before firing an action.
• An Impermissible verdict correctly blocks an action.
• All new code is covered by unit and integration tests.
• The main README.md or library documentation is updated.