Namespace fidelity for non-standard-namespace documents and standalone serialization

Following the #15 review, two namespace-fidelity gaps remain for inputs outside the library's target shape (Xcode exports, which are in the standard XLIFF 1.2 namespace). Neither causes data loss; both are namespace-/byte-fidelity issues on non-standard input, distinct from the root-attribute work in #16 and the Header-prefix work in #18.

## 1. Preserved ``/`` nodes round-trip non-idempotently for a non-`xliff`-namespace source

`Bundle.from_xml` tolerates an `` root that isn't in the XLIFF 1.2 default namespace (it checks only the root's local name). On write the root is forced into `urn:oasis:names:tc:xliff:document:1.2`, so a preserved `` deep-copied out of a namespace-less source is re-homed under it. The first serialization emits the group with no `xmlns` (it inherits the forced default); reparsing that output puts the group *in* the xliff namespace, so the second serialization emits a redundant `xmlns` on it. The output is stable after one round-trip, but the first parse's `to_s` differs from the second's:

```
# input root: … … … (no xmlns)
pass 1:
pass 2:
```

## 2. Standalone `Header#to_s` / `File#to_s` can emit namespace-incoherent fragments

A `` child parsed from a document in the xliff namespace re-serializes via the standalone `Header#to_s` with its wrapper element in *no* namespace (it is created in a fresh, namespace-less document) while a preserved child redeclares the xliff namespace:

```
header.to_s
#=>
#=> x
#=>
```

In the full `Bundle#to_s` path this is masked — the wrapper inherits the forced default namespace from `` — so it surfaces only in standalone fragment serialization.

## Proposed fix

Re-home preserved nodes into the target namespace on write (or carry the source's namespace context through the deep-copy) rather than relying on inherited defaults, and give the standalone `Header#to_s`/`File#to_s` the same namespace context the full-document path supplies.

## Scope

Split out of the #15 review, which is scoped to Xcode export support. Xcode's exports are always in the standard XLIFF 1.2 namespace, so neither gap is hit in the library's primary use case, and content always survives (no data loss). Related to #16 and #18. The limitation is documented in the README's "Conformance and limitations" section.

Start with Bundle.from_xml and the standalone Header#to_s and File#to_s paths, then review the README's "Conformance and limitations" section for the intended namespace behavior. Reproduce both examples and verify that preserved nodes and standalone fragments retain coherent namespace context and that repeated serialization is byte-stable.

Written by the indexing model from the issue text.