Support trusted repository-owned configuration and triggers

## Problem

Repository-specific automation currently has to live in each user's global Graith configuration. That makes useful project policy—such as running the repository's canonical lint command after relevant file changes—personal, path-dependent, and easy for contributors to miss.

A repository should be able to commit Graith configuration so everyone who clones it receives the same trigger definitions. Because a trigger can execute commands, cloning a repository must **not** be sufficient to execute that configuration: explicit, local trust confirmation is an essential part of the feature.

## Example

Today, every user has to add something like this to their user configuration:

```toml
[[trigger]]
name = "lint-on-change"

[trigger.watch]
repo = "~/Code/example"
paths = ["**/*.go", ".golangci.yml", "go.mod", "go.sum"]
debounce = "120s"

[trigger.action]
type = "command"
command = "make lint-only"
timeout = "10m"

[trigger.action.deliver]
inbox = "{session_name}"
required = true
```

Instead, the repository could contain an illustrative configuration such as:

```toml
# .graith/config.toml
[[trigger]]
name = "lint-on-change"

[trigger.watch]
repo = "self"
paths = ["**/*.go", ".golangci.yml", "go.mod", "go.sum"]
debounce = "120s"

[trigger.action]
type = "command"
command = "make lint-only"
timeout = "10m"

[trigger.action.deliver]
inbox = "{session_name}"
required = true
```

`repo = "self"` is illustrative; repository scope could instead be implicit in repository-owned configuration.

## Trust and security requirements

Repository configuration is untrusted executable policy. Graith should therefore:

- require explicit local confirmation before activating repository-owned configuration for the first time;
- track trust independently for each repository—trusting repository A must not trust repository B;
- show the repository identity, config path, proposed triggers/actions, commands, and requested capabilities in the confirmation;
- store trust locally, never in the committed repository configuration;
- identify repositories robustly enough that replacing a directory's contents does not inherit trust accidentally;
- re-confirm when configuration changes materially or requests additional capabilities, while avoiding prompts for semantically irrelevant edits;
- never load active policy from an agent's mutable worktree, where an agent or PR could edit the config and cause the daemon to execute it; use a defined trusted source and document update semantics;
- prevent repository configuration from granting capabilities beyond the user's/session's ceiling, including disabling sandboxing or adding filesystem, network, socket, or process access without separate authorization;
- fail closed on invalid, unsupported, or untrusted repository configuration and expose the reason clearly.

A command such as `gr config trust ` could provide a deliberate non-interactive path, while interactive clients could present the same review and confirmation. Exact CLI design is open.

## Configuration semantics

Please define and document:

- discovery location and schema/versioning;
- how repository, user, and built-in configuration merge and which settings may be overridden;
- whether config is read from the default branch, canonical checkout, or another immutable/trusted source;
- when trusted config changes become active;
- trigger name namespacing across repositories;
- paths and command working-directory semantics;
- how users inspect, trust, revoke trust, disable, or locally override repository configuration;
- how `gr trigger list/status` and config diagnostics show each setting's origin and trust state.

## Acceptance criteria

- A committed repository configuration is discovered for that repository without a user-specific absolute path.
- The user must explicitly trust it before any action executes.
- Trust is scoped per repository and can be inspected and revoked.
- Material config/capability changes require an appropriate new confirmation.
- A mutable session worktree cannot silently change active repository policy.
- Trusted repository triggers bind to current and future sessions/worktrees for that repository only.
- Repository configuration cannot exceed the caller's capability ceiling.
- Config and trigger inspection identifies the source file and trust status.
- Merge, reload, failure, and security behavior are documented and covered by tests.

Start by tracing the existing configuration discovery, trigger loading, trust handling, and `gr config`/`gr trigger` CLI entry points. Define the repository identity, trusted source, merge and reload semantics, then cover trust, capability limits, failure behavior, and inspection with tests and documentation. Done means all listed acceptance criteria are implemented without executing untrusted repository policy.

Written by the indexing model from the issue text.