Fix migration, publishing, and artifact workflows

[waple0820]

Outcome

• makes legacy one-shot shares truthful and explicitly revocable without confusing them with Channels
• fixes draft publishing, single-Revision history, Fork continuation, non-library layout, and the built-in Welcome artifact
• warns on non-portable relative dependencies and permits only safe loopback Bridge origins on any local port
• adds a tested, atomic remote deployment with rollback

Verification

• python3 -m unittest discover -s tests -p 'test_*.py' — 21 passed\n- node --check app.js, channel-store.js, validator.js\n- browser smoke: contract, Channel store, repair\n- browser interaction: draft publish disabled; single-Revision preview; Templates/Contract inspector hidden; Fork handoff; non-default-port Bridge; legacy share live → retire → HTTP 404\n- remote staging deployment on the target host, isolated port, with health and static bundle verified\n\n## Owner self-review before merge\n\n1. Could this rewrite or lose retained evidence? No. HTML bytes and Revision lineage remain immutable; legacy revoke only unlinks the exact path after filename-prefix and full-SHA verification.\n2. Could a stale client misreport a public link? The new independent normalization marker updates both first-time and already-migrated IndexedDB records; legacy links remain visibly live until explicitly retired.\n3. Could remote deployment destroy runtime data or leave a broken service? Runtime shares stay outside the release tree; target tests run before swap; health failure rolls back the application directory and service.\n4. Did the fix broaden local Bridge trust? Only syntactically exact loopback hosts are accepted across ports; arbitrary origins, userinfo, paths, and lookalike hosts are rejected.\n5. Is the user-visible flow actually exercised? Yes, with headless Chromium on the running app and a separate real remote staging service.\n\nReady to merge after CI confirms the same checks.