Ground the repo docs and move presence provisioning to a declared spec

Align AGENTS.md with the FT-WP- prefix the hub already registered, and
rewrite INTENT.md and SCOPE.md, which were still the generated stubs and
carried none of the composed-post framing the interface is built around.

Fix two artifact inconsistencies: R-1's retry comment still described
POST /v1/hall-entries idempotent on entry_id, from before the reframe to
composed posts; and the seed pressure record listed only one of the two
hypotheses that cite it. Rename it to match its id.

Replace the manual T01-T03 route with FT-WP-0002. The Bot API cannot
create a bot or a channel, so provisioning is an MTProto client acting as
a designated operator account (Canon INT-03), driven from a declared
presence spec owned by the campaign. One bounded human bootstrap remains
and docs/provisioning.md says why it cannot be removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0172sgCZEEDJcnQmr4SGDvKa

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1361245@bnt-lap001
Assistant-Session: b3b428ef-f3e6-4688-b091-01f71461d66a

revisions/R-1.yaml

@@ -27,8 +27,8 @@ revision:
     # failing fast would turn a rate limit into a lost entry.
     timeout_ms: 30000
     retry:
-      # Only GET is retried by the connector; POST /v1/hall-entries is
-      # idempotent on entry_id, but the retry decision stays with the adapter,
+      # Only GET is retried by the connector. POST /v1/channel-posts is
+      # idempotent on post_id, but the retry decision stays with the adapter,
       # which knows whether Telegram accepted the message.
       max_attempts: 1
     circuit_breaker: