Add the oop-platform role and r2_existing_cluster scenario (deploy, federate,
e2e, undeploy), a k3s role for plain Ubuntu hosts, and tests/r2_e2e. Verified
on two local k3d clusters and on two i2cat VMs driven over SSH.

The k3s role now installs agents too: a node with k3s_server joins that
server with its token, and uninstall removes agents with k3s-agent-uninstall.sh.

deploy.yml follows the helm-2.0 chart's names (identity.*, encryptionKey,
publicBaseUrl and allowInsecurePartnerEndpoints at the top level). With the
old keys Helm ignored them silently and every FM announced itself as
oop-local. FM's Service is a NodePort, since partners call its E/WBI and send
callbacks from outside the cluster.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

A partner only sees our zones if an agreement grants them, and it learns
them from the CreateFederation answer, so the agreement has to exist first.
Each oop_platform_partners entry takes an optional agreement (zone names,
GSMA terms, allowed requests); fm_partners.py resolves the names through SRM
and creates it before federating. A changed agreement replaces the active one,
which is suspended; an unchanged one is left alone. The federate scenario
grants oop_platform_partner_agreement to every partner it finds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The test VM run used SRM's TF-SDK branch, where app listing works, and FM's
partner detail now embeds agreements. Remove the obsolete strict xfail on
listing and check the detail's agreement ownership separately from the
partner summary fields.

Validation: run-test.sh e2e on the three test operators: 22 passed, 1 xfailed.

Federation Manager now keeps one agreement per partner
(oop/code/federation-manager!40):
a second POST /internal/agreements gets 409 agreement-exists.
fm_partners.py posted a new agreement whenever the inventory terms
changed and suspended the old one, so a re-run with changed zones or
terms failed.

agree() now PATCHes the partner's agreement with only what differs:
API types, zones (always with their terms), terms, status back to active,
no end date, and a start date no later than now. With no agreement it still
POSTs one. An FM from before one-per-partner may hold several; the one it
applies is edited and other active ones are suspended, as before.

Validation on test-op1 (FM develop + fix/zone-sync-limits), partner
operator-2:
- old script, changed terms: 409, playbook step fails
- same terms on an agreement with an end date: updated valid_until
- re-run: unchanged
- added flavour: updated zone_resources; removing it again: same
- suspended agreement: updated status; FM sent ZONES REMOVE then ADD,
  both delivered to OP-2
The testbed agreement was restored afterwards.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

playbooks/scenarios/r2_existing_cluster/README.md covers k3s on plain
VMs, the oop-platform role and what the umbrella chart creates
(databases, Keycloak realms and clients, NATS, NodePorts), how the
encryption keys are protected, where SRM's zones come from, how
federate.yml derives partner records and agreements, what the e2e
suite checks, what undeploy keeps, and the known gaps. It is written to
move unchanged to the Open OP documentation site later. The scenarios
README now points to it instead of repeating it.

inventory/r2.example.yml now matches the inventory the test operators
run on:
- chart branch refactor/helm-2.0, since helm develop still has the
  Release 1 charts (helm!15 brings Release 2);
- one SRM zone per operator through oop_platform_extra_values. SRM
  doesn't discover zones from the cluster (ADR-0059): without a
  bootstrap topology it offers none and agreements fail;
- an oop_platform_partner_agreement example, and plain-HTTP partners
  allowed for test networks.

Every Mermaid diagram renders with mermaid-cli 11.4.2.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The Release 1 automation had gone stale and nothing in Release 2 uses
it. Removed (142 files, about 10.7k lines):
- scenarios all_in_one, full_oop, dual_oop, full_oop_existing_cluster
  and every playbook under playbooks/tools
- roles artefact-manager, demas, homer, i2edge, lite2edge, kind-cluster,
  node-feature-discovery, prometheus, zot, and the MongoDB-era
  federation-manager, oeg and srm
- the kind, Prometheus, node-feature-discovery and prerequisites
  infrastructure playbooks
- inventory group_vars, profiles, hosts.yml and
  local_kubeconfig_execution.yml, secrets.example.yml,
  test-template.yml
- docker-local-deployment/
- docs/ and mkdocs.yml: the Release 1 guide, published to its own Pages
  site; user guides belong on the Open OP documentation site

What stays: roles k3s, helm and oop-platform, the k3s and
r2_existing_cluster playbooks, tests/r2_e2e and role-template. The
READMEs, CONTRIBUTING and roles/README.md describe only that now.

CI: syntax-check runs every k3s and r2_existing_cluster playbook against
inventory/r2.example.yml; python-smoke compiles fm_partners.py and the
e2e tests; the docs and pages jobs are gone. ansible.cfg no longer
defaults to the removed hosts.yml, so every run names its inventory.
community.docker, community.general and the docker pip package are
dropped: nothing left uses them.

Release 1 stays at tag r1-final (master before Release 2).

Validation: yamllint, ansible-lint (production profile, 0 findings) and
--syntax-check of all six playbooks pass on the result.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The example zone declared query_available_resources bound to the
k8s-local control path. TF-SDK's kubernetes adapter serves only
workload, so that binding came out of discovery with no actions and no
runtime kinds, and placement could never select it: it read as if SRM
could check free resources when it can't (ADR-0002, SRM keeps no
capacity).

r2.example.yml and the scenario README now declare workload alone, and
the README says why, and that the adapter deploys into SRM's own
cluster, in the namespaces under workloads.namespaces.

Checked: yamllint; the rendered topology parses with TF-SDK's
BootstrapTopology into one workload binding (activate, update,
terminate, read_runtime_state; helm, container). The previous version
gave query_available_resources 0 actions.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

feat(r2): deploy, federate and test OOP on k3s

See merge request !3

chore: keep Release 2 only, remove the Release 1 stack

See merge request !4

Extend platform acceptance for Release 2.0.0

See merge request !9

Synchronize the Release 2.0.0 E2E baseline into develop

See merge request !10

Release 2.0.0: deployment automation and E2E validation

See merge request !12

Make Release 2.0.0 E2E results readable and traceable

See merge request !11